Salesforce.com

Salesforce: Programmatically Populating Sample Data Post-Deployment

by

I’m not sure if this concept is obvious when reading my previous post, so I thought I’d run through it with a specific example.

Rule one of packaging – Finish your bolognese first!

Let’s say that you’ve created what can only be described as an exemplary application in the form of a Managed Package. Although your user interface is beyond compare, you’d also like to populate some of your core objects with example data. Some options that immediately spring to mind are:

  1. Get the person that installs the package to call you, and you can do it post-installation.
  2. Get the person that installs the package to create sample data manually post-installation.
  3. Give the user a “Start Here” page with a call-to-action – such as a commandButton – that fetches the data from some API and parses into object data.

Option 3 is pretty excellent, especially now that you can package Remote Site Settings but I think we can do one better. And when I say better I mean simpler and with fewer potential points of failure.

Read more

Salesforce: Enhanced Custom Settings

by

Okay book’s done, now where were we? Oh yes software development, right? Programming software engineering application development h4x0R-ing. Oh how I’ve missed getting my mitts dirty so without further ado…

Now this one goes right about... here!

Some time back Custom Settings were introduced on the Force.com Platform and we all star-jumped in the air, w00ting to anyone who would listen. Up till this point – if you’re anything like me – you were using custom objects to hold configuration data, whether this be lists of language-codes, or operational settings such at outbound web service endpoints, usernames, passwords etc. With Custom Settings you finally had a place to put this information – a home if you will – for your lonely, orphaned Control Data.

Quite quickly however I realised there was still a gaping hole that could be filled with Custom Settings but just didn’t feel right. Lists of data (such as currency codes and descriptions) fit really well into this structure but more serious Control Data that you only need to be listed once-off (such as important URLs, flags to active/deactive modules in your application, usernames and passwords) just don’t seem like they really belong with this other crowd. A quick list of reasons highlights this:

  • Control Data is typically entered once off and creating an entire Custom Setting for a single line of data feels like a waste.
  • Custom Settings are data so they can’t be deployed with code, they must be created after the fact. Control Data should be a little more important than regular data, it needs a smarter vehicle than plain-old data entry.
  • If you’re creating packages you want as much autonomy for your clients as possible. If you use custom settings there will have to be that “Create data in Custom Setting X__c” step in each and every deployment.

    Read more

Salesforce: Using basic email templates from Apex code

by

A few weeks ago I noticed a number of questions in the forums around how to use email templates from Apex classes. I Googled a few keywords and come up with very little. I then trawled the documentation but came up empty-handed. Eventually it was Eclipse that provided the knowledge required, and I thought I’d share it with the good ol’ developer community.

One part of the process is discovering that Salesforce stores all sorts of items as records in objects; some of them being email templates, user information and even Apex class bodies (scandalous). All you have to do is query them. The other major part is finding that the method you need is missing from the Apex documentation.

Read more