Archive for the ‘’ Category

How Stuff Works : Roles and Profiles

November 3, 2012 Leave a comment

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.

Categories:, security

Custom Settings : How and Why !?

April 20, 2011 1 comment

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 :

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

January 22, 2011 1 comment

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

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 be with You !

%d bloggers like this: