Render Visualforce Components Dynamically Based on Object Level Security

We recently came across an interesting situation that I’m sure many Force.com developers have faced at one point or another:  While using VisualForce with standard controllers in the context of a single object gives you access to a fair number of useful standard components exposed by the platform, when you venture beyond the single object or require functionality beyond what the platform gives you “out-of-the-box,” the custom code can pile up fast.

The specific use case that we had to address dealt with dynamically exposing components on the VisualForce page based on the object level security of the logged in user’s profile – in this case, it was buttons (apex:commandButton) and links (apex:commandLink). Because we were displaying input fields (apex:inputField) and output fields (apex:outputField) from a number of different custom objects, and because the actions corresponding to these buttons and links were custom PageReference methods that did a lot of data manipulation, we couldn’t simply reference standard actions such as {!save}.  And because not every user had access to the CRUD function associated with a given custom button or link, we wanted to only show them buttons and links that corresponded to an action that they could actually perform, rather than leading the user down a path that would ultimately throw an exception and frustrate them.

We knew we could write a fairly complex set of sObject describe methods that would populate boolean variables which we could then reference in the redered=”xxxx” attribute of the button and link definitions, but there had to be a better solution – we weren’t looking for a shortcut, but we didn’t want to leave the client with a ton of code that would be difficult to maintain and update over time. The solution ended up being elegant and straightforward, and leveraged a VisualForce global variable called $ObjectType that we didn’t realize was as powerful as it turned out to be.

The VisualForce documentation doesn’t do $ObjectType justice:

A global merge field type to use when referencing standard or custom objects such as accounts, cases, or opportunities as well as the value of a field on that object.

What salesforce.com should state in the documentation is that the $ObjectType is essentially a way to perform sObject describes natively in the context of the VisualForce page, without having to write a single line of custom controller or controller extension code.  It’s a pretty powerful function, and the only reason we went down the path of using it as a replacement for complex sObject describe methods is that we came across this page in the VisualForce Developer’s Guide, and thought to ourselves that if we could check object accessibility using $ObjectType.accessible, which looks a lot like the ‘isAccessible‘ sObject describe result method, then we might be able to use the similar nomenclature to check for object editability, deletability, etc.  This turned out to be the case, and we had our solution.

So let’s say you want to have a ‘New’ button on your VisualForce page that corresponded to a custom PageReference method called ‘newRecord’, and you only wanted that button to be visible to users that had ‘Create’ access on the corresponding standard or custom object.  What you want to do is something like this:

<apex:commandButton action="{!newRecord}" value="New" rendered="{!$ObjectType.myCustomObject__c.createable}" />

Using $ObjectType.objectName.createable returns a boolean (true/false) value that tells you whether the logged in user has the ability to create (the ‘C’ in CRUD) new records for the ‘myCustomObject__c’ custom object.  If the user does not have the necessary object level security, the expression will return ‘False’ and the component will not render.  If the user does have Create access, then the button will render because the expression will return ‘True.’

While we did not test this method with every possible sObject describe method, we did use it to create an ‘Action’ column to mimic the standard ‘Edit  |  Del’ pattern that you see on standard Salesforce list views, so we know for sure that you can check the ability to access, create, edit, and delete records for a given object.  The VisualForce code looks something like this:

<apex:pageBlockTable value="{!getSomeRecords}" var="r" cellpadding="8">

<apex:column width="10%" >

	<apex:facet name="header"><b>Action</b></apex:facet>

	<apex:commandLink action="{!myCustomEditLink}" rendered="{!$ObjectType.myCustomObject__c.updateable}">
		<apex:outputText value="Edit"/>
		<apex:param name="editId" value="{!r.id}"/>
	</apex:commandLink>

	<apex:outputText value=" | " rendered="{!$ObjectType.myCustomObject__c.updateable && $ObjectType.myCustomObject__c.deletable}"/>

	<apex:commandLink action="{!deploymentDelete}" onclick="return confirm('Are you sure?');" rendered="{!$ObjectType.Deployments__c.deletable}">
		<apex:outputText value="Del" />
		<apex:param name="deleteId" value="{!r.id}"/>
	</apex:commandLink>

</apex:column>

and so on…

As you can see, we were able to dynamically render the ‘Edit’ and ‘Del’ links, as well as the ‘ | ‘ spacing character all based on the CRUD / object level access of the user accessing the VisualForce page.  This saved us a lot of time, and will be fairly straightforward to maintain and update over time.

Here’s a little cheat sheet:

Show a component only if the user has ‘Create‘ access to an object:

<apex:commandButton action="{!newRecord}" value="New" rendered="{!$ObjectType.myCustomObject__c.createable}" />

Show a component only if the user has ‘Edit‘ access to an object:

<apex:commandButton action="{!editRecord}" value="Edit" rendered="{!$ObjectType.myCustomObject__c.updateable}" />

Show a component only if the user has ‘Delete‘ access to an object:

<apex:commandButton action="{!deleteRecord}" value="Delete" rendered="{!$ObjectType.myCustomObject__c.deletable}" />
Mike Topalovich Salesforce Technical Architect in Chicago
Mike Topalovich - Salesforce Certified Force.com Platform Developer I Mike Topalovich - Salesforce Certified Force.com Platform Developer II Mike Topalovich - Salesforce Certified Force.com Developer Mike Topalovich - Salesforce Certified Force.com Advanced Developer
Mike Topalovich - Salesforce Certified Mobile Solutions Architecture Designer Mike Topalovich - Salesforce Certified Force.com Platform App Builder Mike Topalovich - Salesforce Certified Administrator Mike Topalovich - Salesforce Certified Advanced Administrator
Mike Topalovich

Hi, I’m Mike. I help companies like yours do business in new ways with Salesforce.


I am a freelance Salesforce Developer, Architect, and CTO as well as a part time instructor for Salesforce University.


Connect with me today to discuss how I can become a part of your team on an ongoing retainer basis.


Mike Topalovich on EmailMike Topalovich on FlickrMike Topalovich on LinkedinMike Topalovich on RssMike Topalovich on Twitter

Leave a Reply