This week I want to share a scenario which we encountered recently when working on a client project. We were required to make many changes in one go, all of which had small individual impact, but which resulted in significant logistical challenge when put together. All this combined ensures that new and existing users would have a hassle-free experience when using Salesforce.

 

The objective was seemingly straightforward for this case: A new app (group of tabs) has to be deployed to a new group of users, in an org where an existing group of users use a different app. None of the users or the functionality of one group is relevant to the other. In other words two different teams are using two different functionalities, which are however dependent on the platform. Sounds simple enough, right?

Background

The existing users belonged to a sales team and used the Sales app. The new application consists mainly of custom objects but there was one object shared between the two apps – Accounts. We wanted to ensure there is no interference between these two groups of users, so that users see only saw what they need to see. This was important, not only from the data access perspective, but also to keep the Salesforce environment neat and user friendly without cluttering both apps with elements that were not relevant to the respective groups.

 

Possible Unintended Consequences

If we had just deployed the app without any other changes, the following could have arisen:

  • Users would have been asked to select a record type when creating a new account, while this should not be something they ever encounter
  • Reports for accounts would have shown irrelevant results
  • Account list views would have shown inappropriate records

 

Our Considerations

In order to keep the org tidy we looked at the following areas:

  • App: We made the new app accessible only to new users and hidden from existing users.
  • Profiles and Permission Sets: New users have a separate Profile and an additional Permission Set for the admin. These cover access to objects and record types meaning that new users can only see their Account record type.
  • Roles: All new users had the same new role. This meant we could share a List View between those users only.
  • Public Group: We created this feature to allow sharing access to the right reports folders.

Observations

In practice, this activity highlights the importance of testing before deploying to a production environment. Even a seemingly simple deployment which does not involve the existing users, requires a fair amount of admin acrobatics to cover all angles. Finally, this project was a good challenge to work more closely with a ‘privacy’ variable to ensure that there were no leak in the deployment process.