Getting Started with BMC Remedyforce Permission Sets
Permission sets are an integral part of Salesforce security model and the interaction between Remedyforce and Salesforce permission sets are of particular importance. This topic explores permissions sets and their relevance, notably the relationship with profiles and limitations with Remdeyforce.
Before the Permission Set
Before the Salesforce Winter 12 release, administrators always faced the daunting task of creating profiles for user(s) who required minor functionality improvements to be added to their user profile. This ended up being a logistical exercise of evaluating different profiles that needed to be created because of one or a number of users requiring incremental permissions added to application objects or fields. The result was poor administration regarding user requests for additional access or functionality gains and more additional profiles for the administrator to manage.
So the release of permissions sets in Salesforce Winter 12 was welcome relief as now the administrator had the tools to surgically grant permissions to individuals or groups of users without having to create a multitude of additional profiles.
Before we go into detail what permissions sets represent, let’s recap what profiles are. Profiles are basically a collection of settings and permissions that determine what users can do within Salesforce. Profiles control the user’s access within Salesforce to objects and data, and what they can do within the applications. To give you some idea the extent what profiles can do and below are some of list of settings that can be applied to Salesforce apps built on Force.com e.g. Remedyforce.
|Object permissions||The objects the user can view, create, edit, and delete.|
|Field permissions (also known as “field-level security”)||The object fields the user can view and edit.|
|User permissions||The specific functions that users can perform, like viewing the Setup menu and customizing applications.|
|Tab settings||The tabs the user can view in the app.|
|App settings||The standard and custom apps the user can access.|
|Apex class access||The Apex classes a user can execute.|
|Visualforce page access||The Visualforce pages a user can execute.|
|Page layouts||The page layouts a user sees.|
|Record types||The record types available to the user.|
|Login hours||The hours during which the user can log in to the app.|
|Login IP ranges||The IP addresses from which the user can log in to the app.|
The Permission Set
Like a profile the permission set is a collection of settings and permissions that control what users can do. However, unlike profiles they do not offer all the settings associated to a profile and include some features of which a list of these are below.
- Object permissions
- Field permissions (known as “field-level security”)
- User permissions
- Tab settings
- App settings
- Apex class access
- Visualforce page access
So why Permission Sets?
The first thing to understand are users are only allowed to be assigned one Profile. At the beginning of this paper it was explained that sometimes users require additional incremental permissions to be added without the problem of creating new profiles to support these changes.
Using permission sets a user with a single profile who requires additional permissions could in theory have multiple permission sets that in total incrementally grant access without changing the users underlying profile.
To illustrate this point the next image shows a user with single profile and two permission sets assigned to single profile. The final aggregate permissions equals to the total permissions given to the user. One thing the reader of this paper should also understand is that permission sets only grant permissions they do not deny them.
(Image Source: Salesforce.com – aggregate permission sets)
Advantages of using permission sets
By granting access to custom objects or entire apps to an entire team may not be the best solution at times. Particularly if you only want to grant access to certain applications to few users or a team that is working on a special project. In the past separate profiles would need to have been created and assigned to these individual users however, with permission sets their profile remains the same and you grant the elevated permissions via the permission set. Once complete the permission set can be removed from user records.
Admins can use permission sets to grant access among logical groupings of users, regardless of their primary job function. They give flexibility over user permissions and access settings. An example is that you want to give report access to only specific staff members. You can create a Report permission sets and use that.
One other example is that you may need to extend someone’s access to particular information either fields, objects or applications for short periods of time for example if someone is working within an area as part of temporary work assignment or while co-worker is away on vacation temporary access can be given via the permission set. Once the user no longer requires the additional access the administrator again removes the permission set from the user’s record.
One other primary advantage for Remdyforce is the ability to push out upgrades while keeping the Remedyforce Permission Sets in sync with existing configurations.
Differences between Profiles and Permission Sets
As previously mentioned within this paper the significant difference between Profiles and Permission sets is that user are only allowed one profile, but they can have many permission sets. This means administrators can use profiles to grant the minimum permissions and settings that every type of user needs, then use permission sets to grant additional permissions without changing user profiles.
If a permission is not enabled in a profile but is enabled in a permission set, users with that profile and permission set have the permission, in summary together they define aggregate access.
To understand this further the following tables outline the differences between profiles and permission sets and not only considers the actual differences but also takes into account the relationship with the application as a managed package.
(Table 1 – generic differences between permission sets and profiles)
Users can have multiple permission sets
Only one Profile
They are upgradable
Profiles are not upgradeable
Intended to use for Specific AccessExtending privileges
Use for Generic accessUse profiles to grant the minimum permissions and settings that every type of user needs, then use permission sets to grant additional permissions, without changing anyone’s profiles
Permission sets are additivei.e. you can have multiple permission sets
|Profiles are not additive - only one profile assigned to a user.|
|Not available||Page layouts|
|Not available||Login IP range|
|Not available||Login Hours|
|Not available||Desktop Integration clients|
Remedyforce and Permission Sets
The previous table illustrated some main differences between profiles and permission sets, next we review what Remedyforce displays or controls what users can see based on their Profile and Permission sets. To illustrate this, table 2 shows some of the features of Remedyforce that can be used when applying either Profiles or Permission Sets to control feature within Remedyforce.
Note: that we have compiled this list based on current functionality within Remedyforce as per Spring 15.
(Table 2 – Remedyforce Features for Profiles and Permission Sets)
Profiles/Accounts OnlyThe display broadcasts feature is available within the broadcast record and allows users to assign broadcasts to specific Profiles or Account(s)
|From Address for Email Conversation|
Profiles OnlySet within the email Conversion settings (Remedyforce Administration) whereupon the assigned email address can only be assigned to selected profiles
|Service Request Entitlement|
Accounts/Profiles and Permission sets
When making service request definition available to users both Profiles and Permission sets can be selected within the entitlement tab – service request record.
|Console form assignments|
Profiles OnlyConsoles – Application Settings – Remedyforce administration allows you to assign Console layout to Profiles only.
|Email Services (Enable Profile Access for Apex Class)|
Profiles OnlyStandard Salesforce feature for enabling profiles to access the listener Apex Class – Remedyforce Administration – Email Services.
|Page layout Assignments|
Profiles OnlyStandard Salesforce feature that page layouts cannot be assigned to permission sets.
Profiles OnlyRemedyforce administration –Configure application – templates allows users to assign Profiles to specific templates.
|Console Actions Menu|
Profiles OnlyConsoles – Application Settings – Remedyforce administration.
Profiles OnlyAssign a specific profile to custom quick view – Remedyforce Console.
|Form Assignment (Client form)||Profiles Only|
|Pentaho Package||Profiles and Permission Sets|
|Validation Rules ($Profile)||Profiles|
Table 3 outlines the Remedyforce Permission Sets that are shipped out-of-the-box. This table associates the permission set shipped with Remedyforce and its appropriate user role.
(Table 3 – Remedyforce Shipped Permission Sets)
|Permission Set||User Role|
|ServiceDesk Client||Self Service Client|
|ServiceDesk Staff||Staff Member|
|ServiceDesk Change Manager|
|ServiceDesk Release Coordinator|
The following are some few best practices when applying permission sets and have been compiled from varying communities or gained from general dialogue and support enquires. Although not extensive they should at least give you some idea when applying Permission Sets generally.
a) Select the right balance - permissions sets gives you power and flexibility for granting additional access. However they still should be sensibly managed and not go over the top and create multitudes of permission sets. This means striking the right balance when defining or identifying the types of users who need uplifted permissions. Remember that profiles are used to generalize user access and permission sets allow you to give specific uplifted access.
b) Additional application support - if you intend to load additional applications from Salesforce AppExchange or create your own custom applications remember that use of permissions can greatly simply access for users accessing these new applications.
c) Reuse and reduce- make the permissions sets reusable wherever possible and base these on functions. For example, administrative or team leader functions as well as special access for modules, applications or custom objects that you want to give uplifted access. Remember to try and reduce number of profiles using permissions sets as this will help with overall administration and maintenance.
d) Keep a record – try and record the reason for creating or maintaining permissions sets. In particular discuss with other administrators or reference records why you created permission sets before you add new ones. This is important as you maybe be creating new permissions sets when the permissions and access already exist. Here are few recommendations for keeping track of your permission sets.
- Use detail description while defining permission sets.
- What is the use of permission set?
- Why it was created and date?
- Type of access this will give in brief
- Who you have assigned the permission set to.
e) Salesforce housecleaning - If you plan to use permission sets then it’s advisable to do some housecleaning of your current profiles. Use the opportunity to go through each profile and validate if you really need them, remember permission sets are intended for reducing profiles.
f) Use out-of-the-box – remember that Remedyforce permission sets are upgradeable and apply to three major releases each year and add a lot of functionality and features every release. If you just decide to continue to use profiles remember that you will have to make any required changes manually. BMC recommends that you do not clone the out-of-the-box permission sets because these permission sets get updated with access to new pages, tabs, fields, and so when you upgrade to later versions of BMC Remedyforce these features are already applied. If you need to grant additional permissions to users, create a new permission sets with additional permissions and assign the newly created permission set and the out-of-the-box permission sets to user(s) that require them.
g) In the Best Practices section I will like to see a point mention why it is important to continue with RF OOTB permission sets. Creating a clone and using a custom permission sets can create permission is not recommended. If it has to be done for any specific requirement then the onus is on the administrator to synchronize the changes in permission sets for every new release of Remedyforce.
Assigning Permission Sets
This section explains some ways of assigning permission sets to individuals or groups of users and provides to some useful insight into what methods are available to you.
a) Using Data loader - when using this method of inserting permission sets into your Salesforce organization remember that the import file will need the User ID and the Permission Set ID when you insert records into the Permission set assignment object. https://developer.salesforce.com/page/Data_Loader
b) Using Pentaho user provisioning package – this useful Remedyforce community thread provides the support files for the LDAP Pentaho Package which allows you to import users with Permission Sets and the ability to assign Remedyforce managed package license to imported users. https://communities.bmc.com/docs/DOC-32288
c) AppExchange – Salesforce AppExchange is always useful area to look for additional applications that you possible can use, for administrators looking at reducing the time involved with assigning and removing permission sets to multiple users the AppExchange is an extremely useful site https://appexchange.salesforce.com/
Note: It is advisable that you understand that Applications listed on AppExchange as these maybe chargeable and that you are fully conversant with the details of the applications before installing.
d) Standard Salesforce – you can use the standard Salesforce views to add/edit users to permission sets via the Manage Assignments function. Setup > Permission Set > Manage Assignments.
e) Manually Assign – the final method is manually assigning the permission set. This perhaps the most common method when assigning single or a small number of users to one permission set. Setup > manage users > user record > assign permission set section
Below represents some use cases/examples for assigning permissions sets
- You want to give access to specific app for few users
- You want to give access to reports for few users
- You want to give temporary access to some modules
- You want to expose specific tabs
- Give access as Remedyforce administrator
- You do not plan to change profile but want to give access for specific function
FAQs related to Permission Sets
Table 4 provides responses to some frequently asked questions about permission sets for Remedyforce.
(Table 4 – Remedyforce Permission Sets FAQ)
|Can I delete out of the box Permission Sets?||No. You can delete these types of permission sets as they are part of the Remedyforce managed package.|
|Can I edit out of the box permission Sets?||No. These are managed package and therefore users are prevented from editing these.|
|Can I clone managed package Permission Set||Yes. Users can clone managed package permission sets and use these modified permissions.|
If I clone Permissions Sets can they be upgraded?
|No. Only out of the box permission sets are upgradeable. So always assign out of the box permissions sets at firs then add any special permission sets if you want to use both for additional permission assignment.|
|What considerations are there for not using permission sets as part of any upgrade?|
Manual changes are required after every major release upgrade process for Remedyforce. For additional information on the different scenarios after upgrading Remedyforce Read this
|Permission set licenses, what are those?|
The permission set assignments page shows permission sets with no associated license and permission sets that match the user's license. If you assign a permission set with no associated user license, all of its enabled settings and permissions must be allowed by the user’s license, or the assignment will fail.
Some permissions require users to have permission set licenses to the user and then add the permissions to the permission sets.
Can I just use permission sets and no profiles?
No. Profiles are mandatory and this cannot be removed.
Some Other Useful Links
- The difference between profiles and permission sets
- Overview of the self-upgrade and automatic upgrade processes Read this
- Verifying the self-upgrade or automatic upgrade of your organization Read this
General Reference Material
- Salesforce documentation
- Remedyforce documentation