30 January 2013

Mass edit profiles using Enhanced Profile List Views




In an earlier blog, I discussed the importance of naming and using a profile's description.  What I find talking with admins is that they really need a way to compare and surface more of a profile in order to make informed decisions as well as updates.  To help this process of better managing a set of profiles, we created the Enhanced Profile List Views.

Enhanced Profile List Views enable you to:
Create custom list views of your profiles that give you visibility to the permissions of those profiles
Display profile information including user and object permissions
Print those list views in order to document your permissions
Mass Update your profile's user and object permissions
The last point is pretty important since each time you navigate to the profile screen and make a single change, you have to make approximately seven clicks. By using preconfigured list views, the number of clicks reduces to five, but more importantly, those five make changes across up to 200 profiles at a time.  As a result, you can make mass changes more quickly and have full audibility of those changes in the Setup Audit Trail for compliance and troubleshooting purposes.

HOW TO ENABLE

Enhanced Profile List Views may be enabled for all Enterprise and Unlimited Edition orgs.  To enable it, go to Setup | App Setup | Customize | User Interface and select Enable Enhanced Profile List Views.

HOW TO USE IT

Once you've turned it on, just go to your profile list under Setup  | Administration Setup | Manage Users | Profiles.  This enhanced list view works the same as any normal object enhanced list view with one exception, when you mass update a permission, we'll tell you what else will be changed. That way, you always know the impact of your decisions.  Don't worry if you miss this,  you can always check the audit trail afterwards to see what else was also updated.



To Print a list view:


I'm often asked when we will add more controls like tabs or record types to the list views. Those are all on our roadmap; however, when we talked with our admins, we found that the majority of mass updates needed were around two things: user and object permissions.  There are also some user interfaces already to manage some of the other controls, for instance the page layout - record type assignment matrix or the field accessibility user interface to manage page layout and field level security properties.  But if you feel strongly about specific controls being added to the list view, please add comments and your vote to the idea on the ideaexchange: Easier (faster) way to set profile permissions.

I was speaking with an admin just the other day that had spent the better part of the day manually updating profiles to remove a permission from all of them.  After we discussed the Enhanced Profile List Views, his day long task turned into a two minute long task allowing him to join his colleagues at a happy hour.

29 January 2013

Distributed Administration using Sandbox and Change Sets



One of the primary use cases I hear with distributed administration is the ability to delegate customization access to some setup (metadata) components.  This often includes components like objects, fields, record types, page layouts, workflow rules, etc. that the business wants to control and have a quick turnaround in production.  The source of frustration for the business is that it usually has to wait for a bandwidth challenged System Administrator to make all of their changes. The challenge for the System Administrator is how to ensure that the business doesn't do something that could damage other users, such as deleting a field required in an integration.

While the Customize Application permission governs a user's rights to manage these setup components, and it's possible to distribute this right over a custom object using Delegated Administration, there aren't many options for managing custom components on standard objects or non-object configurations from setup that ensure the level of control and testing that most System Administrators require.

As an alternative to granting the Customize Application permission to the business users or having the business communicating all of their changes in detail for the System Administrator to make, it is possible to use a developer sandbox to distribute the rights necessary for business users or delegated administrators to manage their components. You would not want to give them a full sandbox copy because the System Administrator profile will ignore all sharing configurations and give those delegated administrators access to *all* data within the org.

When a business user wants to manage some aspect of the application, you would:

  1. Create a developer sandbox for the request (don't reuse a sandbox that was created for a separate purpose).
  2. Name the sandbox after the user/business group making the request.
  3. Activate the sandbox.
  4. Give the business user the System Administrator profile making them a delegated administrator over this one sandbox.
  5. Train the distributed administrator how to make changes in the sandbox and create a change set.
  6. Let the distributed administrator make changes to their sandbox setup.
  7. Have the distributed administrator upload their change set to production.
  8. Review the changes that the user has included in the change set to ensure they do not disrupt anything like an integration or Apex.
  9. Deploy the change set to production.
  10. Make any additional changes that weren't included in the change set (for instance, a change to the role hierarchy or sharing rules).

The advantages of this solution are:

  1. You can grant full administrative rights to a user in a controlled environment without giving them access to *all* data or full administrative rights in production.
  2. You can review any changes to ensure the integrity of the production org, which is a benefit to the distributed administrator who made the changes (after all, if something were to break as a result of the distributed administrator's changes, they may be affected as well).
  3. The change set remains active in the org for a period of time allowing for an audit of changes (beyond the setup audit trail).
  4. This process is an optimization over the existing one where you have to create an efficient communication channel for the business to describe all of the changes that need to be made. So a slight delay between when the delegated admin uploads their change set and when it's been reviewed/deployed, is still less time than if the delegated admin had to document all of the changes and communicate them, especially where the changes are routine (i.e. creating several fields or modifying a page layout).

The disadvantages of this solution are:

  1. There is a slight delay between when the business uploads the change set and when it gets deployed after being reviewed. While maintaining the integrity of the org make senses, it can be frustrating when the change is perceived by the business to be minor, such as adding a field or changing a field property on a page layout.
  2. Not all metadata is supported in the metadata API which means some manual changes may need to be made in the production org.
  3. To enable the distributed administrator to upload a change set, you need to give them full rights in that sandbox, including the ability to manage users or modify all data.

28 January 2013

What can Manage Users Permission do?

I had a question come up regarding what the Manage Users permission on a profile actually enables a user to do.

It turns out that it allows a user to do a lot of things and should only be given to a select few users in any org.

If a subset of rights is needed to manage users but not manage Profiles or Sharing, check out the Delegated Administration feature.

Manage Users allows you to do the following:

  • Profiles
  • Manage Profiles (more detail below)
  • Assign Profiles
  • View Field Accessibility
  • Sharing
  • Manage User Roles
  • Manage Forecast Roles
  • Assign Roles
  • Manage Public Groups
  • Manage ALL Personal Groups
  • Assign Public Groups
  • Manage Queues
  • Assign Queues
  • Manage Territories
  • Manage Sharing Settings
  • Recalc Sharing Rules
  • Manage Dimension Categories
  • Manage Sales Teams
  • Manage Account Teams
  • User Management
  • Create/Edit Internal User and have access to all User fields
  • Manage Hierarchical User Fields
  • Assign License
  • Activate User
  • Expire All Passwords
  • Set Org Password Policies
  • Reset User Password
  • Reset Username
  • Reset Email
  • Assign Mobile Configuration
  • Assign Workflow Manager Field
  • Manage a User's Divisions
  • Manage a User's OAuth
  • View Login Histor
  • View Training History
  • Delegated Portal Administration
  • Create/Edit Portal User
  • Edit Self-Service User
  • Other Permissions
  • Manage Opportunity Update Reminders
  • Activate Opportunity Update Reminders
  • Manage SAML Subject


The rights to manage a profile is more complex than what is required for most setup objects. Because of the various relationships between setup components and a profile, (objects, fields, layouts, apex, etc...) there are multiple permissions that govern access to manage *all* aspects of the profile but in reality, there are specific permissions to manage different controls within a profile. To be safe, an Admin with both Customize Application and Manage Users can manage all aspects of a profile. However, if a user only has Manage Users, they can

clone/delete a profile *or* change any of the following:

  • Properties (Description/Name)
  • Page Layouts
  • Record Types
  • Tab Settings
  • Assigned Apps
  • User Permissions
  • Desktop Client Access
  • Login Hours
  • Apex Class Access
  • Visualforce Page Access

If a user has both Manage Users and Customize Application, in addition to everything above, they can change the following:

  • Object Permissions
  • Field Permissions



25 January 2013

Delegating Modify All Data


Yesterday's post on what Modify All Data can actually do generated a brief, but important, twitter thread with Andy Ognenoff (@aognenoff) and Matt Brown (@mattybme) that I'd like to talk about today.

I spend more time talking through Modify All Data than any of the other one hundred thirty some odd user permissions. Yesterday's blog was meant to highlight all of the ways it's overloaded to provide access to data and other things.

An even better way to think of it is that Modify All Data equal System Administrator. While that's not 100% true, it's the way people often think of it. As a result, it now means access to all data, as well as the ability to migrate metadata, create sandboxes, and write apex code. And that's not even all of the permissions that are required when you enable Modify All Data like View Setup and Configuration. In other words, it really means more than it probably should.

There is some hope here. We created a set of object permissions a long time ago called Modify All and View All records. Interestingly enough, these permissions were the original intent of Modify All Data in that all they are really designed to do is ignore sharing for that object - nice and simple. There are some other behaviors tied to these permissions like the ability to unlock records locked due to a workflow approval, but for the most part they were designed to offload some of the need for administrators to assign Modify All Data. For instance, rather than assign Modify All Data to grant access to all Accounts and Contacts, just grant Modify All on Accounts and Contacts.

Another example that comes up a lot with customers I talk with is login-as. Modify All Data is only one way to login-as another user, another is to use Delegated Administration which allows a user with only View Setup and Configuration permission who is assigned to a Delegated Administration group to login as a user in a specific branch of the role hierarchy.

We have discussed all of the other permissions we need to create to provide alternatives to granting Modify All Data and here is where you can help. If you have suggestions of what's most important to you, please let us know, whether its through a comment on this blog, on twitter with the #askforce or #salesforce hash tag, or by participating on the ideaexchange. Your needs will help us prioritize which portions are more important than others. Andy gave me a great example with dashboard management - what's yours?

24 January 2013

What can Modify All Data do?


I had this question come up last Friday: "What can Modify All Data really do?"

We all know this permission to mean, "system administrator".  But we rarely look at the detail of what makes up the second most powerful permission in the Salesforce.com universe.

To give you some idea any user with the Modify All Data permission on their profile can do any of the following things:

Data Tasks

  • Full Access on all objects (Ignores sharing and any other security)
  • Ability to unlock records in a workflow approval process
  • Access to the mass delete page in setup
  • Ability to edit divisions and mass transfer objects between divisions
  • Allow the user to edit shares on objects not owned by them
  • Can import Person Accounts and Contacts
  • Has access to mass update addresses
  • Can delete a pending import
  • Can import solutions even without the Import Solutions perm
  • Can change document owner
  • Can edit opportunity line item unit price
  • Can edit existing case comments
  • Required for deleting case comments
  • Allows editing/deleting of private contacts owned by someone else
  • Allows editing all forecasts
  • Can access mass mails
Administrative Tasks
  • Access to the "empty all org" button in recycle bin
  • Can export an org to sandbox
  • Shows the Data Loader link in setup (But not required to use the Data Loader!!!!)
  • Can enable Salesforce 2 Salesforce
  • There must be at least one active user with Modify All Data in an org
  • Modify all data is needed to delete *all* custom reports for an object

Developer Tasks

  • Access to the Metadata API for a developer
  • Access to the outbound and workflow outbound messaging queues
  • Author Apex requires Modify All Data - so to write Apex, you first must have Modify All Data
User Management Tasks
  • Can edit anyone's quota
  • Can edit sales teams on other users accounts
  • Can Login as another user once granted access
  • Without Modify All Data, you cannot assign a user to a profile that has Modify All Data

Permissions Modify All Data requires (these permissions will be automatically enabled when you enable Modify All Data; conversely, Modify All Data will be disabled if any of the following permissions are disabled):

  • Read, Create, Edit, Delete, View All, Modify All on all standard and custom objects
  • Convert Leads
  • Create and Customize Reports
  • Edit Events
  • Edit Personal Quota
  • Edit Tasks
  • Import Leads
  • Import Solutions
  • Manage Categories
  • Manage Dashboards
  • Manage Public Documents
  • Manage Public List Views
  • Manage Public Reports
  • Manage Public Templates
  • Override Forecasts
  • Run Reports
  • Transfer Leads
  • Transfer Record
  • Use Team Reassignment Wizards
  • View All Data
  • View All Forecasts
  • View Setup and Configuration


23 January 2013

Why

As a product manager, the most important question for me is 'why'. Who, what, when, and where are all important; however, why drives the most interesting conversations when understanding the problem I want to solve.

Often, customers will tell me 'what' they want instead of 'why' they want it. Salesforce.com has an entire site dedicated to providing that dialogue called Ideaexchange.

I love this site and spend a lot of time trading comments on various feature ideas.  It's really about the democratization of product where anyone can post ideas for new features. 

The best posts focus on the question of 'why' rather than just providing an idea of 'what' they want. My colleague and I were just talking about one post in particular, Convert Salesforce.com to Chatter Free, which did an incredible job of explaining the use case why they wanted to downgrade salesforce users to chatter free licenses.

A litmus test I use to figure out if someone is asking 'why' or 'what' is by asking, "if I could give you that feature tomorrow, how would you use it?"

The answer to that questions is always the basis of 'why' they want it and helps me work with my talented team of developers to determine what will actually solve their problem. An example of this is the Record Type Selection in Permission Sets idea with 88 comments to date, mostly consisting of an ongoing conversation to get to the heart of why they actually want it.

All ideas are incredible, but the reason why you want that idea will always be more helpful to create a solution that solves the original problem.

17 January 2013

Comparing Profiles and Permission Sets


I get this question quite a bit and I wish there was an 'easy' button to push that could give you the information your looking for.

The reality is that the concept of 'easy' doesn't scale nearly as well as a user's profile or permission set.

Take an org with 100 custom objects, each object with approximately 50 fields. Add on average 2 page layouts per object with a record type a piece. Include 10 apps, 100 apex classes and 100 visual force pages. For any given profile or permission set, that means there are 11,000 permissions that can be configured ((100*6) + (100*50*2) + (100*2) + (200)) with an almost infinite number of possible combinations.

And that's not even everything that a profile can contain! Add to that 10 profiles you want to combine and compare across 100 users with 20 add-on permission sets and you have a proverbial needle in the haystack.

So when it comes to administering profiles and permission sets, it's really about finding the right tool for the job. There are many tools available to manage these profiles and permission sets, but no single tool I would recommend because every tool begins with a fundamental question, "what do I want to know" or "what do I want to do"?

Examples of questions I frequently hear include:

  1. Who has Modify All Data?
  2. Does Sam Bradley have the right to click on this tab or view that Visualforce page?
  3. What's different between Sam Bradley and Mike Liescher?
  4. What's different between the Standard User and the Basic profiles?
  5. What's different between the PTO Manager and PTO Administrator permission sets?
  6. How can I assign this permission set to 100 new users?
  7. How can I remove the Modify All Data permission from any users with the Basic Profile or have North American Managers in their title
  8. How can I automate the assignment of the API Enabled permission set anytime a user becomes a manager and remove it if it no longer applies?
  9. How can I disable the View All Data permission from all profiles, add it to a single permission set, and assign it to all users who originally had the profile with the permission?
  10. How can I organize my permission sets the same way I organize my business or distribute apps to people?

Each question maps to a specific task that I am performing as an administrator. Now combine each task with the concept that each user, profile, and permission set can contain an infinite number of permission and settings combinations and you have the need to find the right tool for the right job to answer the right question. And each task may map to a different tool or API that can be used to answer it.

There are some great resources to help answer specific questions. For instance:

I did a great dreamforce 2012 session with Sherrie Smith from Paychex Inc where we outlined some techniques comparing and managing profiles: http://www.youtube.com/watch?v=LcqS1KvMvK8

I did another great dreamforce 2012 session with some of my team members and partners where we dug into some of the great tools you can build on top of our API: http://www.youtube.com/watch?v=cUQem7yvL6Q

One of those tools included a graphical interface for comparing users, profiles, and permission sets but looking specifically at their user permissions: https://perm-comparator.herokuapp.com by John Brock

Check out: Using SOQL to determine your force.com user's permissions ( http://blogs.developerforce.com/engineering/2012/06/using-soql-to-determine-your-users-permissions-2.html )

Probably the best tool for a more extensive comparison of profiles is the force.com IDE native compare ( http://wiki.developerforce.com/page/Force.com_IDE ). Mike Chale's comment about using the ANT Migration Tool is another manfiestation of this.

There are some other great open resources that take the MdAPI XML and parses it to show differences like Quick Diff ( http://www.quickdiff.com ), or Model Metrics Diff Dog - Setting up and using

DiffDog for Salesforce.com ( http://www.modelmetrics.com/tomgersic/setting-up-and-using-diffdog-for-salesforce-com-deployment-validation/ )

There are also some great AppExchange Packages including:

The Permissioner by Arkus: ( https://sites.secure.force.com/appexchange/listingDetail?listingId=a0N30000008XYMlEAO )

Snapshot by Dreamfactory: ( https://sites.secure.force.com/appexchange/listingDetail?listingId=a0N300000016cejEAA# )

The key part here really is identifying what you want to compare and why. The why part is pretty important since once you know how profiles are different, you'll want to do something with that information.

Hope this helps some! Give a shout if you want some help with it.

'/e' in the URL keeps permission highlighting alive



I saw the funniest thing the other day when looking over one of our developer's shoulders.

He wanted to enable the Modify All Data permission in a permission set (or profile) he just created.

He searched for the setting using the Find Settings box. It found and highlighted Modify All Data, but it was far enough down the screen that he didn't want to scroll back to the top and click the edit button before scrolling back down to find the permission again.

So he just inserted '/e' in the URL between the permission set ID and the rest of the URL (/0PS3000000000Fj/e?s=SystemPermissions#ModifyAllData).

Next thing I knew, without scrolling around the screen, he was enabling the Modify All Data permission which was still highlighted.

Who knew? Well, he did of course.

About this Blog

I've worked for salesforce.com for almost eight years. I'm telling you this because I want to be clear, I am passionate about the product and believe in Marc Benioff's vision for the company. However, the views and opinions of this blog are solely my own and do not reflect any official salesforce.com policies or views. This is sort of my own personal safe harbor statement.

When I joined salesforce eight years ago as a trainer, I thought that there was a lot to the product. Eight years later, and working as a product manager, I've witnessed exponential growth of everything. More data, more functionality, more acquisitions, more customers, literally more of everything. And in that time, I've accumulated a lot of tips, tricks, and best practices with how the salesforce product works. Basically, I'm a salesforce hacker.

Not a hacker in the lets see if I can break into something and cause random acts of chaos sense. This is a product blog, not a cook book on how to create a denial of service attack against salesforce.com. I'm a hacker in the original intent of the word:
Hacker (programmer subculture), who combines excellence, playfulness, cleverness and exploration in performed activities
Only my hacks specialize in cloud computing and the salesforce platform. Some are more programmatic in nature; however, most involve simple button clicks (to borrow Mike Gerholdt's tagline).

Since becoming a product manager, I've blogged a couple dozen times about what I know. Usually I post after sharing the same information with more than one customer. Unfortunately for me, these posts are littered around the blogosphere. And while they are mainly on salesforce.com properties, I find it difficult to tell people I speak with to search google just to find them.

As a result, I'm creating this product blog to consolidate these couple dozen postings but also to give me a forum for sharing new hacks that I learn about on a daily basis. After eight years doing this, I find that I really only know the tip of the iceberg and everyday is a new learning experience.

14 January 2013

Using SOQL to Determine Your Force.com User’s Permissions


I often get the following question from administrators, “now that a user can have multiple permission sets in addition to their profile, how can I tell what permissions they have?”

It makes sense, after all: a user’s permissions determines their right to do almost anything in an org. For compliance and troubleshooting reasons, it’s important to be able to track down why a user has a certain access right and correct it if need be.

Summer ’12 introduces the ability to answer this question using the permission set API. We’ve created a new field on the PermissionSet SObject called IsOwnedByProfile. This field determines whether a permission set is a custom one or if it is parented by a profile. This is made possible because for every profile, there is one underlying permission set. That way, permissions layer equally across permission sets without having to treat a profile differently. In the setup user interface, you only see the profile but in the API, you can see both the profile and the underlying permission set.

As a result, running the following query in SOQL, for instance in a tool like workbench, will return both permission sets you’ve created and permission sets parented by a profile:

SELECT Id,IsOwnedByProfile,Label
FROM PermissionSet

By adding IsOwnedByProfile to the WHERE clause, you will quickly differentiate between permission sets you’ve created versus those parented by a profile:

SELECT Id,IsOwnedByProfile,Label
FROM PermissionSet
WHERE IsOwnedByProfile = TRUE

Once you have the hang of this, you can start to answer all sorts of questions about your users such as, “which users have Read on Accounts and why”:

SELECT Assignee.Name, PermissionSet.Id, PermissionSet.isOwnedByProfile, PermissionSet.Profile.Name, PermissionSet.Label
FROM PermissionSetAssignment
WHERE PermissionSetId
IN (SELECT ParentId
    FROM ObjectPermissions
    WHERE SObjectType = 'Account' AND
    PermissionsRead = true)

You might need to answer questions about a specific user such as, “what are all of the Account fields where John Doe has at least Read access and why”

SELECT Id, SObjectType, PermissionsRead, Parent.label, Parent.IsOwnedByProfile
FROM ObjectPermissions
WHERE (ParentId
IN (SELECT PermissionSetId
    FROM PermissionSetAssignment
    WHERE Assignee.Name = 'John Doe'))
    AND
   (PermissionsRead = true)
    AND
   (SobjectType = 'Account')

Using permission sets in this way, you can find out why a user has access to an apex page, class or a particular user, object, or field permission, regardless of whether it’s through their profile or permission set.

These SOQL queries are great if you have one off questions about your user’s permissions. If you have a more regular need to query user’s permissions, think about creating a Visualforce page with an Apex controller that uses these queries to find out what your users can do and why.