30 April 2013

How to Test & Migrate Profiles and Permission Sets Using Workbench

I spend a fair amount of time working with customers and partners to understand how to migrate profiles and permission sets from one environment to another.

Migrating metadata between sandbox and production orgs enables customers to create and test org changes without impacting production users. Independent software vendors (ISVs) create customizations like profile settings and permission sets that can be packaged from a developer edition org and distributed to subscriber's sandbox or production orgs.

The good news here is that there is a powerful metadata API (mdAPI) that serves as the backbone for helping you manage these kinds of migration.

The not so good news here is that this API, while powerful, has a lot of flexibility built into it resulting in some behaviors that may seem confusing, especially when it is consumed by different applications.

There are many applications that use the mdAPI to migrate metadata from one environment to another:

  1. Changes sets enables admins to declaratively migrate metadata from sandbox to production and vice-versa. 
  2. The Force.com (ANT) migration tool enables IT and developers to programmatic migrate metadata from sandbox to production and vice-versa.
  3. Force.com IDE enables developers to create and migrate metadata declaratively
  4. Packaging enables ISVs to create custom metadata in a Developer Edition org and allow customer admins to install it in a their sandbox or production org.

Because there is always a chance that any one of these tools will insert their own pre-defiend set of assumptions, I will often test any migration use case using a simple flow that eliminates any specialized behaviors created by an application, allowing me to focus on what is possible using the mdAPI that all of these applications use. This ensures that I can eliminate some of the confusion that may result in migrating my metadata using one of these applications.

Below are some simple steps to try out pretty much any use case that may come up when migrating either profiles or permission sets. If you have any questions why something is behaving the way it is, I would highly recommend trying out a retrieve and deploy using the mdAPI directly using this technique. Once you know how it works with the mdAPI, you can troubleshoot the behavior you may be experiencing in any one of the client applications I mentioned above.


How to retrieve a profile or permission set using the mdAPI:


1. Create your package.xml that will define the metadata types you want to retrieve in a payload and save it somewhere on your computer. I typically start with the following XML that I save in an .xml file. Depending on the use case I'm working on, I hide the metadata I don't want to retrieve yet behind HTML comment tags (e.g. <!-- everything between these tags are hidden -->). For instance, when I want to retrieve object and field permissions, I'll move the CustomObject type below the commented XML with the Profile and PermissionSet types. The following package.xml example will only retrieve the bare minimum Profile and PermissionSet metadata:

<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<!-- **************************  
    <types>
    <members>*</members>
    <name>CustomObject</name>
    </types> 
    <types>
        <members>*</members>
        <name>Layout</name>
    </types>
    <types>
        <members>*</members>
        <name>CustomApplication</name>
    </types>
    <types>
        <members>*</members>
        <name>CustomTab</name>
    </types>
    <types>
        <members>*</members>
        <name>ApexClass</name>
    </types>
    <types>
        <members>*</members>
        <name>ApexPage</name>
    </types> 
    <types>
        <members>*</members>
        <name>ApexClass</name>
    </types>
************************** -->  
    <types>
    <members>PermissionSetName</members>
    <name>PermissionSet</name>
    </types>     
    <types>
    <members>ProfileName</members>
    <name>Profile</name>
    </types>
    <version>27.0</version>
</Package>

2. Log in to your source org that you want to retrieve metadata from.
3. I like to use the workbench tool created by Ryan Brainard by entering the following URL into my browser: https://workbench.developerforce.com/login.php. This tool allows you to focus on the core metadata API.

4. Navigate to migration > Retrieve.
5. Select the 'Choose File' button and navigate in your file system to the package.xml file you created in the first step.
6. Select the 'Single Package' checkbox.
7. Select 'Next' button.

8. Select 'Retrieve' button.

9. After the retrieval is finished, right click on the 'Download ZIP File' link to save the zip file with your metadata.

10. Unzip the ZIP file and start working with each individual metadata file. When you open a .profile file, you can now make changes to specific permissions like loginHours or loginIpRanges. For instance, I might change a loginHours start or end time to reflect a new set of hours when users with this particular profile can login and work.

How to deploy a profile or permission set using the mdAPI:


1. After making changes to metadata in the .profile or .permissionset files, I'm ready to zip and deploy changes to my target org.
2. You will need to zip the directory that you downloaded when you retrieved your metadata. It's important to zip the package.xml file in this directory since it provides the basic set of instructions used in the deployment. Because I use Mac OSX, I typically use the terminal app to zip up my contents rather than rely on the operating system's native compression functionality. One reason I don't zip using the native OSX functionality is that the package.xml file, which is necessary for the deployment, doesn't always register properly unless I use the terminal to zip it with the rest of the metadata files and directories. Open your terminal or command shell application and change the directory (e.g. cd /Users/me/mdapi) where your metadata directory structure exists.

3. Zip the directory using the following terminal command: "zip -r d2.zip r2" where r2 is the source directory with metadata, d2.zip is the target zip file, and -r will ensure that all subdirectories will also be zipped as well.
4. Log in to your target org that you where you want to deploy metadata.
5. Use the workbench tool by entering the following URL in the browser: https://workbench.developerforce.com/login.php
6. Navigate to migration > Deploy.
7. Select 'Choose File' button and find the ZIP file you just compressed.
8. Select the 'Allow Missing Files' checkbox.
9. Select the 'Next' button.

10. Select the 'Deploy' button.

11. When the deployment is finished, you can expand any of the nodes to find and resolve any errors or check your target org to ensure that the deployment was successful.

This tutorial is really only meant to enable testing profile and permission set migration use cases. It can be very powerful when troubleshooting different behaviors you may be experiencing and can even be used to manage your migrations without relying on tools like the Force.com Migration Tool (ANT) or Change Sets.

22 April 2013

Permission Set Best Practice: You Should Try THIS Out at Home


Unlike profiles which have pre-created (or standard) examples like ‘Standard User’ or ‘System Administrator’, permission sets have no pre-created examples in an org.
Below is a list of permission set examples you may want to create and why they are a good idea.
As a general rule, as you remove a permission from a profile and add it back to individual users through a permission set, you reduce the risk that users who share a profile don't have more access than what they need.

Permission Set ExamplesWhy you might want to create them
View All Data
  • Recertify who can view all data in an org to manage the running user of dashboards rather than giving it out to all users in a profile
  • Enables users to run reports and retrieve all the org data
Modify All Data
  • Be the Automated Case User (for Web to Case forms)
  • Be the Default Lead Creator (for Web to Lead forms)
  • Empty the organization Recycle Bin
  • Unlock all workflows
Manage UsersReduce the number of users who can:

  • Create/Modify Profiles and Permission Sets
  • Create/Modify Sharing Rules
  • Manage all aspects of users including resetting passwords
Is Single Sign-On Enabled
  • Roll-out single sign on throughout the organization regardless of a user's profile.
Price Book Administrator (Read, Create, Edit, Delete on Price Book )
  • Consolidate who in Sales Ops can manage products and price books
View Encrypted Fields
  • Control which users have the ability to View Encrypted Fields rather than relying on larger groups of users having this ability
API Only User
  • Manage Integrations more easily by migrating this permission from all profiles to a single permission set
  • Quickly lock all users from the user interface while performing release updates
Customize App
  • Control who can customize more easily by migrating this permission from all profiles to a single permission set
  • Reduce risk that comes with distributing customization rights to more users than is necessary
Approver
  • Use field level security to determine who can approve a record in an approval process

15 April 2013

Use Custom Profiles Where Possible




Standard profiles are salesforce.com's intellectual property.  We will often make adjustments to these profiles permissions from release to release in order to introduce new functionality easily to our customers.  By cloning these profiles, you automatically inherit the new functionality and can always take it away later if you so choose. However, because standard profile permissions are unchangeable, active users assigned to these profiles will automatically inherit this functionality and you will not have the option to remove it unless you reassign those users.
Custom profiles do not typically change from release to release.  When you decide that the cloned Standard User profile should not have View Setup and Configuration, we will respect that change from release to release and leave that permission disabled.
Custom profiles are exactly that, custom.  Unlike standard profiles which do not allow you to adjust user or object permissions, you have full access to modify all permissions.
Standard profiles have their use, but you should limit that use to cloning if you have the ability to do so (Enterprise and Unlimited Editions). In Professional and Group Edition, you may only assign Standard Profiles and cannot customize them.  As a result, you cannot control your user's functional access beyond the assignment of a standard profile.

To clone a standard profile, go to Setup | Administrative Setup | Manage Users | Profiles and clone the next closest profile to what you need. If you are using Enhanced Profile List Views, you can create views into the user and object permissions in the profile to have a better sense of what the closest profile to your needs may be.

To assign a profile, go to a user's record and edit it to switch their profile. It is possible to automate this assignment across many users by using the Web Services API and a tool like the data loader; you will just need to know the profile id and the user id to assign the profile.

Permission Sets Best Practice: Lose Some Profile Weight


Profiles remain an important and necessary tool for the administrator.  Beyond the requirement that every user is assigned to a single profile, certain user settings are available on profiles that are not available on permission sets.

Previous blogs discussed the ability of permission sets to simplify the administrator’s job as it pertains to assigning the appropriate permissions to the appropriate set of users.  There are some additional simplifications available to the administrator who fully leverages that capability in order to reduce the number of profiles within an organization.

It does not take too many job functions within an organization before the possible number of profiles grows quite large.  Beyond the challenge of administering each of these profiles, many screens related to object creation, field creation, page layouts, etc. become more difficult to manage as the number of profiles grows.  By reducing the number of profiles, the manageability of these screens improves.

Because profiles control more user settings than permission sets, it can be a challenge to eliminate some profiles simply because those user settings are important variations within the organization.  However, one user setting that is not available on permission sets, but can -- to a certain extent -- be controlled by permission sets is “Tab Settings.”  In order for a tab to be visible to a user, the tab must be available to the user (either “Visible” or “Available”) and the user must have at least read access on the object in question.  Profiles control the tab setting, but permission sets can control the object level access.  So, if you want your users to have the tab when they have access to the underlying object, you can set the profile to “Visible” (or off, as appropriate) without also defining on the profile any object level permissions for the object.  Then, any individual user’s ability to see the tab will be controlled by the permission sets assigned to them and whether those permission sets grant read access to the object in question.

09 April 2013

Permission Set Best Practice: Reuse, Reduce, Recycle


Consider the familiar scenario where a request is made to provide additional access rights to a particular salesforce.com user.  With profiles alone, the administrator has three options:

  1. Add the new access rights directly to the user's profile.  This has the side effect of also changing the access rights of every other user assigned to the profile, which may not be desirable.
  2. Clone the user's profile, make the changes to the cloned profile, and then assign the new profile to the impacted user.  This avoids changing the access rights of those assigned to the original profile, but now the administrator must keep the old and the new profile's appropriately synchronized.
  3. Grant the user administrative privileges such as Modify All Data, which is like giving out the keys to the kingdom.  This is never recommended unless you want to enable a user to delete all data in the org. Death Star meet Alderaan; Alderaan, get blown up by the Death Star.

With permission sets, the administrator has a powerful tool at their disposal and can simply create a new permission set with the requested permissions and assign that to the impacted user.  While this is certainly an option, there is a better way.

When a request comes in to grant additional access rights to a user, the administrator should take a step back and ask some important questions:

  • What is the job function, task, or process that requires these new access settings?
  • Do we already have a permission set for that?
  • If not, what are all the permissions and access rights required in order to perform this job function, task, or process?

The end goal is to use the changes that naturally happen within your organization to reinforce and strengthen the practice of using permission sets to encapsulates the permissions and access settings required for each job function within your organization.  By using the incoming change requests to either correct existing permission sets or identify new job functions, the administrator can ensure that there exists the appropriate number of permission sets corresponding to the identified job functions within the organization.  In asking the above questions and ensuring that a permission set exists which represents the entirety of the new job function requested, the administrator ensure they have something that can be reused across the entire user community.