If you are a salesforce admin, we are all aware of the dreaded problem of accounts and contracts in one setting under Org Wide defaults which cause havoc in our life. Now, why is this a big deal?? If you have sales teams or all users who need access to all your accounts and your Sales ops teams need access to modify contracts only to prevent any major issues, it is really not possible to do this with point and click in Salesforce. This is a major pain point for every Sales operation user who wants to ensure that contracts are managed by them and sales teams just provide the information to create the contracts. So how do we manage it? Will the Salesforce team look at creating org-wide defaults for contracts separately!! You hope so but is safe harbor right!! 🙂
So how do we ensure accounts are globally accessible and contracts can be restricted to users only? So here are the options and solutions for it.
Lock the accounts (Org Wide Default) 😛
Before you open your org-wide defaults to the Gods, I would say let us make the org-wide defaults for accounts as private. You might wonder why I said, Gods!! Right because it is open to the entire world. So making accounts, contracts as private, nobody in your salesforce kingdom can see the accounts except for the creators and owners of accounts.
Lock the Contracts
How can you lock the contracts? You might wonder if you had locked the accounts org-wide default as private, are contracts locked to right? 😉 Yes, they are locked because accounts and contracts share the same org-wide defaults.
Open the accounts to the world
I can now see your sales team crying foul on you as a salesforce admin for not letting them see their favorite accounts? Guess what!! They create their own accounts and you end up in a world of duplicates. You are now blamed for the pipeline as well. Really!! 😉 So how in the world can you make sure your accounts are globally accessible? Sharing rules to the rescue. You can create a sharing rule where you can share all accounts created by the sales team or owners to all users using role hierarchy. You can use internal users as role or any other role. Similarly, you can create a sharing rule for accounts created or owned by the non-sales users and share the accounts to those users.
Locking the Contracts really well
Now once the accounts are exposed to the world, you might have this crazy requirement where certain business units should not be exposed to certain types of users. This can be contracting types like your types of products or services. So how do you ensure these users do not see the contracts? Profiles object security settings to the rescue. For those users who are part of a profile, you would go their profile object settings and go to contracts and uncheck the access to contract object for reading, edit, delete, view all, and modify all. How does this help? Even though you opened up the contracts to all users by sharing rules, by ensuring the CRUD permissions unchecked, these users will never be able to view, edit contracts. So now you got your contracts completely locked to those users who have to be restricted.
Selectively share contracts
If you have a use case where you want to hide a certain type of contracts for certain types of users, do we have a solution? Yes, we do and it is called dynamic record pages. I would like to thank David Hungness for his great share on leveraging record pages to hide contracts for certain types of users.
If you look at the above screenshots, you can easily create a dynamic record page with filters based on contract fields and user fields and hide the entire detail page to the users. How cool is that!! Now you can also go one level cleaner and create custom permission which is on the screenshot above and assign it to profiles and permission sets as well. This is a much better option compared to the user field as you can scale it to any type of user and can be audited easily.
Pros of using custom permission compared to the field on the user object
- Can be scalable to any type of user
- Create a separate permission set and have it audited.
- The dynamic record page solution does not hide the contracts from reports, list views, and search results. So to overcome it, you will need to create a separate page layout, separate tab on the record page, and hide it and show it based on a filter.
Sales ops who need to live in contracts
For sales ops folks who need access to all contracts and will still need to manage them, you can do the following.
- Have a separate profile for Sales operations
- Have the CRUD permissions for contracts as read, edit access based on your needs.
- Create custom permission called Full Contract Access and assign it to the Sales Ops Profile or permission set if needed.
Gotchas you need to consider
As part of their security setting with accounts and contracts accessing the same security model, you have to consider the following which can be security breaches if not done properly.
- Once accounts are shared globally with all users, contracts will be accessible to all users unless you change the profile CRUD permissions to contract objects for every profile.
- For profiles requiring selective access to contracts, ensure that the CRUD permissions for contracts are set to Read or edit and have a component on the lightning record page with filters to access data. Just CRUD permission alone does not help.
- Now the real threat is the contract document or file which gets created. This typically gets attached as a file to the contracts. To ensure the security of the document, you might want to create a custom object and create a link to the file so that you can control the contract document completely.
As always feel free to post your comments and email me at firstname.lastname@example.org for follow up questions. I would be happy to share an architect solution kit if you are in the decision making process for this.
Subscribe to our mailing list and get tips to maximize salesforce to your email inbox.
I am honored to have your subscription. Stay tuned for tips to maximize your salesforce investment
Something went wrong.