This documentation supports the 20.19.02 version of Remedyforce.

To view the previous version, go to BMC Remedyforce 20.19.01

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.

Profile Reminder 

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 e.g. Remedyforce.

Object permissionsThe 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 permissionsThe specific functions that users can perform, like viewing the Setup menu and customizing applications.
Tab settingsThe tabs the user can view in the app.
App settingsThe standard and custom apps the user can access.
Apex class accessThe Apex classes a user can execute.
Visualforce page accessThe Visualforce pages a user can execute.
Page layoutsThe page layouts a user sees.
Record typesThe record types available to the user.
Login hoursThe hours during which the user can log in to the app.
Login IP rangesThe 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: – 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)

Permission setsProfiles

Users can have multiple permission sets

Only one Profile

They are upgradable

Profiles are not upgradeable

Intended to use for Specific Access

Extending privileges

Use for Generic access

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 anyone’s profiles

Permission sets are additive

i.e. you can have multiple permission sets
Profiles are not additive - only one profile assigned to a user.
Not availablePage layouts 
Not availableLogin IP range
Not availableLogin Hours
Not availableDesktop 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)

Remedyforce ModulesAvailable

Profiles/Accounts Only

The 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 Only

Set 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 Only

Consoles – Application Settings – Remedyforce administration allows you to assign Console layout to Profiles only.
Email Services  (Enable Profile Access for Apex Class)

Profiles Only

Standard Salesforce feature for enabling profiles to access the listener Apex Class – Remedyforce Administration – Email Services.
Page layout Assignments 

Profiles Only

Standard Salesforce feature that page layouts cannot be assigned to permission sets. 
Templates (Remedyforce) 

Profiles Only

Remedyforce administration –Configure application – templates allows users to assign Profiles to specific templates.
Console Actions Menu

Profiles Only

Consoles – Application Settings – Remedyforce administration.
Quick Views 

Profiles Only

Assign a specific profile to custom quick view – Remedyforce Console.
Form Assignment  (Client form)Profiles Only
Pentaho PackageProfiles 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 SetUser  Role
ServiceDesk ClientSelf Service Client
ServiceDesk StaffStaff Member
ServiceDesk Change Manager
  • Change Manager
  • Change Initiator
  • Change Coordinator
ServiceDesk Release Coordinator
  • Release Owner
  • Release Manager
  • Release Approver
Remedyforce Administrator
  • Staff member who can perform administrative tasks in BMC Remedyforce
  • System administrator

Best Practices

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.

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.

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

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)

QuestionsKnowledgebase Response
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 SetYes. 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.

  • The difference between profiles and permission sets

Permission set FAQ

  • 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
Was this page helpful? Yes No Submitting... Thank you