The views, ideas and opinions expressed in this blog are solely my own. They neither apply nor are necessarily subscribed to by any persons or organizations I may be affiliated with, either personally or professionally.

How Stuff Works : Roles and Profiles

If I had a penny for each time I’ve seen someone trip over the difference between Roles and Profiles, I’d be a millionaire. Not really, but I’d prolly have enough to pay for a month’s coffee. And I don’t like my coffee cheap. So here goes.

Roles and Profiles are different for want of a better word. Complementary even.

The Organisation Wide Default (OWD) is the foundation, which decides whether default record sharing for the object is Private / Public Read Only or Public Read Write. This is the most restrictive data setting.

Roles have to do with data visibility, where the data you can see is dependant on your position in the Role Hierarchy and the Sharing Settings.

When the (OWD) is Private, Sharing Rules become available to open up the OWD data restrictions to groups of users or roles and subordinates. These can either be ownership based or criteria based(with some limitations)

Another way to share data is through Apex sharing where you can programmatically insert share records based on custom logic too complex to encapsulate as Criteria Based Sharing Rules.  Then of course, there is good old Manual Sharing!

Profiles control what you can do with the data that is visible to you, certain administrative permissions and of course which objects in the schema you have access to and the level of access (CRUD).  Field Level security, for example, lets you control at a Profile Level which fields are visible or read only to certain profiles.

The View All Data and Modify All Data permissions on the Profile are exceptions because they bestow ‘SuperCow Powers’ on the users with that Profile. Hence why they are normally granted only to Full System Admins. (There are also per sObject View All and Modify All Permissions, which can be leveraged to grant certain Profiles complete access to certain sObjects)

Additionally Profiles also control which Apex Classes and Visualforce pages the user has access to.

Permissions Sets are a way to provision profile permissions in a modular fashion so you can group a bunch of related (Profile) permissions. They supplement the permissions already granted to a user by virtue of their user profile.

In summary, the Security model is a little bit like an onion – comprising of layers that work together to constitute the whole. As you peel away the layers, you begin to understand the part each one has to play in ensuring that Users can only see and do what you will for them as an administrator !

Practise What You Preach !

To put into perspective all that we’ve discussed, let’s attempt to understand the things that need to be in place for a User to see an Account record. For starters, the Profile needs to have, as a minimum, Read access on the Account sObject. Now to view the data, the User needs either to be the Owner of the record, above the Owner in a Role Hierarchy, or granted access via Sharing to a Public Group or Roles and Subordinates.

It therefore follows that say if  you’re not able to view an sObject tab, it will be down to your Profile, which is probably missing Read Access. If however, you can see certain records, but not others, it is then down to your Role and the Sharing Settings.

Custom Settings : How and Why !?

Hard-coding and good code are a match made in hell. RecordTypeIds are most vulnerable to this abuse, and we’re are all familiar with the frustration of finding that code that worked in environment A, suddenly stops working when it is promoted to say test. Why? Because possibly RecordTypeIds are different across the two environments.

Why hard-code when you can use Custom Setting for stuff like this ? Custom Settings are a SOQL inexpensive way of storing your configurable parameters in the safe confines of the Salesforce database, with all the conveniences of a custom object – create / edit via point and click – standard salesforce !

Under the hood Custom Settings are much like a Custom Salesforce Object, save for you cant have triggers on them. Most obvious difference, amongst others.

What’s more, they even come in two flavours ! Hierarchical and List.

Hierarchical Custom Settings let you define values at different levels – Org Wide, Profile-wise or even User – Wise. They are accessible in Config (Validation Rules, etc) as well as Apex Code.

List Custom Settings are structured similar to records held in a custom object.

To create your first Custom Setting, navigate to Setup > Develop > Custom Settings

Here you can create your first List or Hierarchical Custom Setting. You will find this menu is similar to the one for creating a custom object. However the types of fields you can create on a Custom Setting are restricted – for eg. no picklists or lookups or formula fields.

Let’s say we created a Custom Setting called Test__c and added Text Fields Value1__c and Value2__c.

Its simple enough to do via the UI – click Manage on the CustomSetting screen, and it will let you add records. Observe the similarity in doing this via Apex

Test__c test = new Test__c(Name='One', Value1__c='1stValue', Value2__c='2ndValue');

insert test;

To access this record we created, we can summon it without SOQL !

Test__c testSelect = Test__c.getInstance('One');

System.assertEquals(testSelect.Value1__c, '1stValue');

Special Considerations for Hierarchical Custom Settings :

We spoke about the ability of Hierarchical Custom Settings to hold different values for a field per Profile, User and Org-wide.

To make this possible, Hierarchical Custom Settings have a field called SetupOwnerId, which holds the Id which the record pertains to.

So, if I wanted to create a record pertaining to user Joe Bloggs

User joeUser = [Select Id from User where Name='JoeBloggs'];

Test__c joesSetting = new Test__c(SetupOwnerId=jobUser.Id, Value1__c='Joe1', Value2__c= 'Joe2');

insert joesSetting;

Then, to access this, you just need to pass in Joe’s Id when you retrieve this Custom Setting instance

Test__c joesTest = Test__c.getInstance(joeUser.Id);

System.assertEquals('Joe1', joesTest.Value1__c);

In summary, to get a reference to a specific List Custom Setting, we use CustomSetting__c.getInstance(NAME), whereas for a specific Hierarchical Custom Setting, it’s CustomSetting__c.getInstance(PROFILE_OR_USERID)

Last, but not the least, CustomSettings are not part of config that would move across in an Environment Refresh or such. The data rows will have to be moved across environments via DataLoader, much like reference data records.

Needless to say, please do read through the Salesforce documentation on Custom Settings : http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_methods_system_custom_settings.htm

O Reference, why art thou null !? Apex Bloopers Series : 1

I have recently acquired a penchant for responding to posts on the Salesforce Discussion Boards. Its the only way I know of constantly challenging the limits of my limited knowledge about this rapidly evolving platform.

As part of the Apex Bloopers series, I aim to capture some of the most common mistakes we make inadvertently, and wonder why the Universe is conspiring against us when everything looks like it should ! Some of these are not really mistakes, but some things are just not so obvious when you get started with Apex. So Bloopers, for want of a more catchy title !

The first one that springs to mind is a case where you check for relationship references in a before / after insert trigger.

Now if you try inserting a Contact and look at the debug logs, you will see that con.Account.Name evaluates to null. However the AccountId field does hold the Id of the related Account. That does seem a bit odd when you come across it for the first time. It isn’t exactly intuitive.

The reason this happens is because in before / after insert triggers, relationship fields are not reference-able directly, as there is no way for Salesforce to know which fields of the related object it should load and make available. It cannot load all Account fields and make them available, for reasons of efficiency (err… or so I’m told !)

So, if you need to access fields on related objects, you will first have to query for them and then use the references.

Needless to say (really !?), in a before / after Update trigger, the Contact.Account reference will evaluate to a value !

So much for this time, until we meet again, May the Force.com be with You !

The ‘God’ particle

The ‘Cloud’ like most other new-age concepts is a much abused term. What really is the Cloud? After having read several verbose and belabored definitions, a strange analogy permeated my consciousness, as if by divine inspiration.

The Cloud and God have a lot in common. In fact they have identical characteristics. And since mankind has invested a great part of its existence in defining and understanding God, most of you should be able to identify with this analogy !

If you can see or touch or manipulate Him, then you’ve got the wrong person …

If you can see or touch or ‘tweak’ software that claims to be ‘Cloud’, then its fake ! True Cloud Computing is about abstracting the all the innards, so that the only evidence of its existence even is the experience, without having a clue about where it is, what it’s made of or even who else can experience it. And the overall experience is broadly the same for everyone – if it can’t fly kites for you, then it can’t fly kites for me !

To Him who asks show me one place where there is God, I say show me one place where He isn’t …

If the experience is limited to when you’re within the confines of your corporate network or any particular infrastructure, then again what you’ve got there is the fake Cloud ! Real cloud computing is about the same experience everywhere, delivered seamlessly. Omnipresence is everything !

“No weapon can cleave Him; nor the fire burn Him, no waters can make Him wet, nor the wind dry Him up”

The ‘real’ cloud is indestructible, in that it has sufficient disaster recovery built into it so that it can survive most reasonable disasters. And mirror locations are certainly within not 100 metres of each other !

You can’t bribe Him, but if enough of you pray for the greater common good, then He will grant your wish !

We’ve already established that if you can manipulate or tweak it, then you haven’t got the real deal.  However, the Cloud does listen to its worshippers. And if enough people pray (read vote on IdeaExchange !) for something that is in the best interests of all and sundry, then be rest assured that it will be part of the next maintenance release, which by the way rolls out seamlessly ! Never underestimate the power of prayer !

And the list of metaphors can continue until eternity. In summary, the real cloud is about delivering a uniform experience seamlessly, no matter where you are, who you are or what you do. Everything else is just marketing noise.

If Winter comes, can Spring 11 be far behind ….?

Spring 11 is one power packed release from the good folks at Salesforce.com.

Those of you who didn’t manage to catch the Salesforce Spring 11 Webinar – the recorded sessions are available here.

If I were to cherry pick a few of my favourite new features, then the list would read :

• Field-Sets : Arguably the one that gets the most applause. Not to mention, it will take admin-developer relations to an all time high !  Fields sets are a new collection type that can be defined on objects. Admins can define / change these. Developers can then use them as a sort of enumeration to iterate over in their VisualForce pages, without actually referring to the individual fields. So configuration can control what gets displayed on a custom VF page. Does make you wonder why that didn’t come sooner. Soon you’ll wonder how you ever did without it !
• Inline VF Editing : Simple VF tag makes VF display elements inline edit-able.  Need I say more ?
• Governor Limits : Less is More ! Considerably increased, however there are no longer disparate execution contexts (test, triggers, etc) – uniform limits. Like someone tweeted – If you can’t get it to work with these limits, you’ve not done it quite right !
• Rest API is now GA.

And then there are other features liked the Visual Flow Editor coming of age, albeit not fully in the cloud. The designer must be downloaded and installed on your desktop. You can also now write triggers for Chatter Feeds and Comments. (You can also ‘like’ Chatter posts – a la’ Facebook !)

Oops, nearly missed this one – Chrome is now officially supported !! So much so that Dave and Sandeep actually did the demo on Chrome !

So sign up for your pre-release Spring 11 Org and try those bad boys out.

Until this power packed release hits our sandboxes, May the Force.com be with You !

Hello world!

This is how it starts in the world of computer programs. Hello World. So well Hellp World !

Sit back and enjoy the sights and sounds as I take you on a journey through my trials and tribulations as I challenge the boundaries of technology to meet the needs of people at work.

A cloud-side view of things !