I am really very excited about the imminent full release of Force.com Sites.

For those of you unaware of what it is, it allows one click publishing of salesforce.com pages directly to a website.

Integrating with your CRM with your website has long been a challenge, and now I'm really excited to see that this is a real achievable goal, without the need to invest in costly custom server side development or middle-ware platforms.

Salesforce.com asked their community to build some sample Sites, to demonstrate the power of the system, before this goes Generally Available, here are 3 sites that have been built solely in Force.com Sites:

- Gaming E-Commerce Site

- Force.com Sites Wiki

- Force.com Sites E-Commerce Shop

What are some sample applications you can use for sites?

- List your upcoming Events (Campaigns) on your website and enable smarter registration.
- Online E-Commerce and Purchasing via a credit card gateway?
- Manage your forms (e.g. Contact Me, Trial Downloads, Whitepapers) dynamically without the need to re-program web-to-lead forms.

Literally, any time you need Dynamic Content on your website, where the content is (or could be) in salesforce.com, you can now do this!

See BT's new business website and the press release from Astadia.

Salesforce.com have a strong vision to move from being solely a direct sales organisation, to a more channel focussed company.

In short, BT are now reselling salesforce.com, along with an implementation package bundled in from Astadia (a US Salesforce.com consulting partner).

I wonder if or when we will see Telstra or Optus partnering with salesforce.com in Australia.

This is one I’ve come across a couple of times with clients wanting to use the native renderAs attribute of the apex:page component to create ‘higher’ quality merged PDF documents such as Certificates or Letters of Appreciation.

Now the concept is simple you design a nice visual force page using a mix of visual force components and html to create a neat layout for your print document and create a custom controller or extension to query the data you need in your merge document. (Be sure to use the div id="NewPage" style=""> /div wrapper to ensure that each page rendered has the same margins)

Once you have your rendered document you click print and find that your images have come out ‘blurry’ but your text remains fine!!!

Now without boring you with a rant about image resolution, pixel dimensions, vectors and document size we have 1 major issue causing your blurry image quality problem “Image Resolution”.

Image resolution has everything to do with printing your image and has nothing to do with how your image appears on your computer screen, which is why images you download off the internet appear much larger and of higher quality on your screen than they do when you print them.

The Solution:

Instead of using small source .JPEG images in your apex pages, use much larger source .JPEG images and squash them down with the image tag. This essentially squeezes more ‘image’ into a fixed portion of your apex page.

So whereas previously you might have had a .JPEG file that was 300px by 70px as your company logo, replace it with a .JPEG image that is 1000px by 700px (of good quality of course.. don't just blow up your 300px by 70px image!!!!!) and squash it back down to 300x70 using the image tag.

apex:image id="theImage" value="/img/myimage.bmp" width="300" height="100"

Obviously using larger .JPEG files will increase your load time for rendering and will use up more storage space if you intend to reference your file from within your salesforce instance so there’s always a bit of a juggling act between performance and print resolution, but hopefully you can find the right balance.

A good way to test whether or not your images will come out blurry is to open up your PDF and zoom in to 400%, if you notice any image degradation at 400% then your image will print blurry.

Any software consultant worth their weight in requirement specs will have no doubt come across a client or system user who drops the line “if it’s not broke don’t fix it”. In Australia we are blessed with a large serving of cynicism and fear of change (in my opinion) and while in many cases this is great when it comes to Business processes and system implementations it can be a hurdle that is hard to overcome.

See the problem with the “if it’s not broke don’t fix it” ideology is that it doesn’t take into consideration factors like changing business requirements, innovation or the ever increasing workload of the Australia employee. While it is obviously dangerous to jump head first in with the newest hottest trend/fad, it is ‘AS’ dangerous to maintain the status quo on the grounds that it has worked fine in the past. While I might be slightly biased due to the nature of my vocation, the value in understanding the potential negative and positive impacts of a new approach, system or methodology on a business or process should be apparent.

Businesses and individuals should leverage the critical way in which Australians approach change. If you or your employer are fortunate enough to be at the crossroads and there is a chance to review what you do and how you do it, ask the important questions:

• Why and what do we do?
• How do we achieve this?
• Is there are better way to carry this process?
• What are the positive and negatives of investing in innovation?

Tying back to the title of this post, I think the phrase should be amended to “if it’s not broke don’t fix it, but if there is a better way to do it, IT’S BROKEN!”

One of the reasons why salesforce.com is successful, is because it is meta data driven.

What this means, is that when you make customisations in salesforce.com, no code is changed, your changes are stored as records in the meta data layer.

This type of customisation has been done for a long time on consumer websites. For example, when you log into Amazon.com, you can show a different home page or layout depending on how your user profile is set up. You get your personal look and feel and login account, despite the fact that you are accessing the same website as millions of others.

Salesforce.com borrowed this approach.

When you first sign up to salesforce.com, you get a clean 'Org' as it's called, much like a fresh sign up to Amazon.com.

You then go about making changes (customising) the system. Every customisation you make is stored in Meta-Objects, Meta-Tables, and Meta-Records. You can actually get access to the Meta Data API, and query these tables, and make configuration changes via web services for example.

So what am I getting to?

Well, having meta data is great, it allows me to easily customise the database, without the need for actually changing a single thing at the database level. This is the one reason why Salesforce.com can push out updates that dont break their existing client's configurations.

But what about when I install applications from the Appexchange?

Well, a Native-Managed Application (as it's termed), from the Appexchange, is in fact a meta-data snapshot. So someone else has configured salesforce.com, saved their configuration as a template of sorts, and put it up on the Appexchange. It is stored as a collection of meta data.

You install it, and it copies those meta data configurations to your Org, and, if it's a managed App, it locks it down so you cant change it.

The entire point I wanted to make with this post, is a problem I see with the entire concept of the appexchange and native managed apps.

The great thing about salesforce.com is that it is customisable via Meta Data - but if I download say a recruiting application from the Appexchange, this app itself is a set of Meta Data, that I cannot change.

Since when I deploy Recruiting from the appexchange, and I want to change the name from 'Candidates' to 'Applicants', I cannot, since it's already been changed and locked down in meta-records.

So much of the benefit of salesforce.com has been stripped, when you buy a module from the Appexchange.

What we need, is Meta-Meta-Data.

We need the ability to customise managed applications, from the appexchange, without the Appexchange vendor losing the ability to push out updates seamlessly and without losing integrity of the code....

I just find this interesting.... will salesforce.com release Meta-Meta-Data? Maybe if I coin a buzzword for it, Web m.0? Or Meta Cloud Computing?

This press release gives a good snapshot of the current SaaS market and salesforce.com's role within it.

For me it was a good read.

My colleague passed me this link it's a Seth Godin presentation at TED.
Similar ideas to Moore, Gladwell, and Chris Anderson.

Related to marketing strategy, I found it entertaining.

How can I cover such a broad subject in one blog post...

Well it's nigh impossible..

But to summarise there are 3 key trends which I think will shape the next decade:

Social Networking
Email, I believe, is becoming non existant. I receive many important notifications through my facebook account, or my linked in account, and the richness and relevance of this information is greatly extended in comparison to a singular email.
Not only will Social Netoworking drastically change the way every marketer in the world operates (mass email marketing is all but dead right now unless its context specific, segmented, and drip fed), Social Netoworking will become a unified shared platform of user authentication and a source for data enrichment for every software platform in the future. Social Networking will replace email. Facebook or Google or another vendor will incorporate social networking tools as a corporate email replacement option.
Social Netoworking will drive the meta-internet, and will also drive context based content. I will have a single social profile, which every device I own or software I use will authenticate through. I will log into my internet enabled on demand pay tv service at home, with my social network login. Then advertisements on television will be delivered directly to me contextually based on my social network profile. The games I play on my TV will have in game product placement, driven by the data in my social network profile. Social networking will be the channel for every form of communication we have, whether it be making a phone call, sending a message, having a birthday party, or running a corporate event.

Mobility
The computer screen will be relegated to one of the least used forms of accessing your software.
Increasingly, internet access is being embedded into every electrical device we use. Initially this in the form of mobile devices, such as blackberries and iphones etc. This will be extended to absolutely everything.
What does this mean?
It means that we need a singular channel for software delivery.
In the past, for example, microsoft, would offer different 'versions' of software for each platform you wanted to install the software on, so you'd download MS App for your Windows Vista PC, then a different version for your Apple (if it was offered), then a different version for your phone, then a different version for you Pocket PC... the list would go on.
As the number of devices increases to infinity, there is no way any software vendor can offer their software on every possible device.
How can we deliver software to any and every device, without the need for versioning....
The answer is Internet based software.
Ubiquitous connectivity will be paramount, and wireless technology will be the primary means of internet access. Every Internet enabled electronic device will come with an ability to automatically connect to a wireless internet provider (where it be Mobile based technology or long range Wi-Fi / Wi - Max style networks).
We will access our software, as a service, and we will expect it to be internet enabled and accessible through every electronic device we own.

Cloud Computing
If you take these first two trends, you will notice they both indicate that the internet will become the primary source of information and primary channel for information delivery.
That said, in 10 years time, I believe every piece of software used by an organisation or an individual will be hosted by a cloud computing infrastructure. The IT department will no longer manage servers or networks, just simply manage a constant internet connection. IT managers and CTO's will no longer talk in megabytes, but simply be drivers of organisational change and operational efficiency through the access and placement of information.
Look at Google, salesforce.com, Amazon, Facebook, Linked In, Microsoft Azure, SAP By Design, the list literally goes on and on.
There will be a convergence between consumer and business based cloud computing infrastructures. Integration between software will turn from being extremely difficult coded connections between different systems, to being all Web Services or other Web XML based. Pre built connectors will dominate the integration space and even custom integration will be able to be developed quickly. When you subscribe to Google Apps, or Microsoft Azure, you will be able to almost instantly, connect it to your Corporate Facebook account, your salesforce.com system, your Amazon S3 account, your On Demand Business Intelligence platform, your On Demand Telephony account... more and more and more.
Microsfot Windows be slowy deteriorate from being an operating system, to becoming a means of accessing the internet. The Operating System market will commodotise and maybe Google, Apple, Linux, another commercial vendor will build a lite OS which essentially be a window to the internet, as the internet will house every piece of data, and every application we need in our home and business lives.


So the advice I can give, if you are involved in making any decision about software strategy for your organisation, keep these trends in mind, and partner with vendors who share this vision.

Hot off the press,

http://www.salesforce.com/aloha.jsp

I think it looks nice... puts a stronger emphasis on their platform offering, which is good.

Steve Cakebread the CFO for salesforce.com was set to retire, as I understood it, about 2 years ago. He then deferred his retirement to stay on for another 2 years at salesforce.com.

It was no surprise that he has now decided to move on, but I guess the surprise for me was that he was not actually retiring, he is in fact moving over to Xactly Corporation, an Appexchange partner for salesforce.com, and is becoming their CFO.

See press release here.

This move draws my attention to Xactly, I've heard about them before, but I didnt realise they had the attraction power to draw someone like Cakebread.

I've met Steve Cakebread once, and seen him present a number of times. He's an amazing orator, and the knowledge I gleaned from a 1 hour session with him 3 years ago in in the Sydney salesforce.com offices was immense.

So I'm going to check out Xactly some more, see what is so amazing about their product!

When undertaking any substantial body of work, whether it be a development (coding) or project rollout, the methodology refers to the steps taken to get from beginning to end.

As a software engineer myself, I recall back in university days, we'd learn time and time again about the Waterfall methodology, image courtesy of wikipedia below:


This was a strict process, where typically the entire scope of the project was planned out at the beginning, and then the project manager would move the project through to subsequent stages. A key principle of the waterfall methodology, is that if requirements change, one must move back to the start of the process. This methodology brings a lot of discipline to project management and it was designed to ensure that the outcome exactly matched clients initial requirements.

There were a few problems with this approach though, it assumed that clients requirements were fixed and it also ran with the ethos that software developers or business analysts needed an exact blueprint of requirements and design before they could commence.

Some say that this approach showed a lack of faith in software developers and business analysts, because the project manager would have to assign them a detailed list of business requirements (written down to exact specification) before they could commence work.

The other key problem was that customers didn't always know their requirements, or could not express them clearly, and typically customer requirements would change over time. This meant that monolithic projects would last for 12-18 months and longer, because each time a customer wanted to update the system design to meet a change in their business process, the whole methodology would start from the beginning again.

A newer approach to project management is one called Agile, principles of Agile PM are:
- Software Developers & Business Analysts know what they are doing
- Requirements should be captured, but not to the infinite extent required by Waterfall
- and importantly, the customer should always get a functional release at the end of each 'Sprint'

This approach would set about discussing the top requirements with a customer (say 5-10 high level requirements), then the Business Analysts & Developers would commit to delivering these within a 'Sprint', a sprint would be a window of days, anywhere between 14-60 days usually. The programmers would work in a less structured and more collaborative way and use their own initiative and knowledge to deliver the smaller set of requirements within the rapid timeframe.

Because software development was a risky business back in the 80's and 90's, people would use this same waterfall methodology, which is also used in construction for example, in building a multi billion dollar building or bridge. But requirements dont change that often when building a bridge.... and you cant just say to a Construction Engineer, go ahead and build the arch how you see fit...

Although due to advances in software technologies, it is now a reality that usable functionality can be delivered within short periods of time (Sprints), and that developers can take a high level requirement and deliver it without the large amounts of planning and paperwork that waterfall requires.

I was watching this webinar, about how salesforce.com themselves use an Agile approach in delivering functionality to their customers.

We've built our consulting practice within my company on an agile approach also, by giving more responsibility to the developer or consultant, and by starting with a reduced set of high level requirements, and keeping paperwork low.

I feel this enables us to react faster to customer requests and deliver more value to clients because we wont over analyse and document everything we are going to do, we will document at a high level, and then simply proceed and do it, this way we can present a prototype quite rapidly to our clients, and get feedback.

I thought it may be a good idea to share some basic information on how to write a Trigger in Apex within your salesforce.com instance.

But to start, why would I need a trigger?

Well essentially, a trigger is an action performed by the system, and it's called a 'Trigger' because it is invoked, or called to execute when triggered by an action in salesforce.com.

It is really like an advanced form of workflow.

For example, if I have a business rule that on the account screen, if someone enters the employee size, greater than 500, then I want to update a field on the account to 'Enterprise Customer', I can use a trigger to do this, for example, go to:

Setup -> Develop -> Apex Classes -> New

Then choose the type as Apex Trigger.

A basic portion of code:

trigger myTrigger on Account (after insert) {

Account myAccount = trigger.new[0];
if (myAccount.Employees > 500) {
myAccount.Type = 'Enterprise Customer';
update myAccount;
}// else nothing
}

So a few things to note, in the first line:

trigger - this defines that our class is a trigger, and that the returned object will be a variable called 'trigger'
myTrigger - this is the name of my trigger, we could have called it anything really
on Account - this means that the action we are undertaking will occur when a change is made to the Account object, we can specify any object here
(after insert) - there are a variety of specifiers you can place here, after insert means that this code will execute whenever a new Account is inserted into the database, and it will execute immediately after the new account has been inserted, the modifiers you can use are:

• before insert
• before update
• before delete
• after insert
• after update
• after delete
• after undelete

Now that covers off the first line of code.
The second line of code, 'Account myAccount = trigger.new[0];', this is important.
When a trigger is executed, the code is passed a list of objects, not just one object. The list is actually an array list of sObjects which are the primitive type of objects in salesforce.com.
The reason why we are passed a list of sObjects is because salesforce.com executes triggers in batch. So for example, if you were uploading data to salesforce.com, it actually writes these to the database in batches, each batch size can vary (depending on the upload settings), but will typically be up to 200 records.
So imagine that this trigger is executing after an upload of new accounts, or for example, two users insert an account at exactly the same time, in these cases you would be passed an array of sObjects in the 'trigger' object.
So whilst my code works, it is actually badly written in this example, what we always should do is find the size of our trigger (trigger.size()), and loop through each element and perform the update on each, because in my code right now, it will only reference the first element, trigger[0].
I am assigning the value trigger[0] to an Account variable.
I can then access the fields on the account, as you can see I change the value of Type. Then I update the database. The commit to the database is fired once the code completes.

This is a basic example of how to write a trigger. There are other things such as 'Govener Limit Exceptions' and 'Order of Execution Rules' which need to be considered, but I hope this gives any budding trigger coder a start in the right direction.

The great thing about triggers, is that you can make salesforce.com do absolutely anything you want. For example, maybe every time an account is entered, you want to do an outbound web services call to an address validation service (such as QAS), and then you want to do an outbound call to your accounting package, you really can perform any logic you like, this is the really neat part.

The US Army are using salesforce.com for recruiting.

There are quite a few companies using salesforce.com for recruiting, and I recall electronic arts were also one of these, they won an award for the best use of technology in a recruitment process.

I'm looking forward to when salesforce.com builds out further it's ISV Channel, so that way we can have an array of tailored recruitment products using the force.com platform.

I did an earlier post on Appirio's social network marketing tool, which connects salesforce.com and facebook.

I found the proper website for this, so check it out at:
http://appirio.com/products/rms/

It's $25k (presumably USD), and looks pretty nifty.

So I've been pained for too long that my accounting package and salesforce.com do not connect.

Unlike the professional plumber who has the worst faucets in his own home, I've decided to take a step to correct this.

I've spent a bit of time on building something I call, 'Integrate Now'.

Its a native force.com app, built with a modular archtecture, which allows you to integrate endpoints into salesforce.com.

The first module I've written is an outbound web services call to my accounting package, Saasu. I have got the prototype running now, and it correctly reads in my invoice data from Saasu and populates it in salesforce.com.

I need to add testing, error resiliency and a few more features, but I hope to get this done on the weekend, and I'll even package it on the appexchange, so fellow salesforce.com and saasu users can finally integrate.

Some teasers below.

This is also a common need in salesforce.com development. How to call an Apex method via a button press.
I thought I'd put a post explaining your options on how to achieve this.

Firstly, create a new VF controller extension, which extends the object on whose screen you'll need the button.

For example, you want a button on the Account page which triggers some custom apex, so go ahead and create a new controller called, AccountExtension, (this is a new Apex class):

public class AccountExtension {

// global class variable for the Account object that
// triggered this page view
private final Account a;

// constructor for controller extension
// takes the standard controller as input
public AccountExtension(ApexPages.StandardController stdController) {

// takes the Account object which spawned the page view
// retrieves the standard controller and casts it
// and assigns it to this page
this.a= (Account)stdController.getRecord();
}

public void myMethod {
// put your custom apex code here
// typically your would instantiate another object and execute it
// but a code block works just the same
}

public String getMethod {
// put your custom apex code here
// typically your would instantiate another object and execute it
// but a code block works just the same, in this case a String is returned
}

public void setMethod(String mystring) {
// put your custom apex code here
// typically your would instantiate another object and execute it
// but a code block works just the same, in this case a string must
// be passed to the method
}
}

Now once you have saved this, create a new VisualForce page, there are 3 ways you can initiate custom Apex via a visualforce page, each require the extension with the code.

Option 1 - Action Method
By following the below code, you can see as an attribute in the vf page, we have something called 'action'. The action attribute will execute whichever method it is provided on page load. In this case I've put the action in the page element, but it can be in other elements too.

<apex:page standardcontroller="Account" extensions="AccountExtension" action="{!mymethod}">
<apex:sectionheader title="My Page">
</apex:sectionheader>
</apex:page>

Option 2 - Getter Method
This approach is different to an action method, as it is executed in line with the rest of the vf page, and getter methods can return a value.

<apex:page standardcontroller="Account" extensions="AccountExtension">
<apex:sectionheader title="My Page">
{!Method}
</apex:sectionheader>
</apex:page>

Option 3 - Setter Method
Setter methods pass values from the UI to an apex method. It is also executed inline on the page.

<apex:page standardcontroller="Account" extensions="AccountExtension">
<apex:sectionheader title="My Page">
<apex:inputtext id="my lovely string value" value="{!Method}">
</apex:inputtext>
</apex:sectionheader>
</apex:page>

The tricky bit for me was the naming syntax. For example, to be a getter method, the name of method in the controller class must begin with get, and similarily with setter methods, it must begin with set, although for action methods, you can call it from it's full name.
Then just go ahead and create a new custom button on the Accounts page, which links to the Visualforce page you've just created, and voila!
You can read more about this here