Record ownership in Salesforce may seem simple but can cause its fair share of issues if it’s incorrect – varying from unwanted data access to skewed reporting.
In this post, we will go through the basics of record owners and explain why they are so important in Salesforce.
The Perks of Being a Record Owner
With great power comes great responsibility – even without being a Salesforce Administrator sometimes. Record ownership makes it extremely easy to identify the person responsible for a certain record that; for example, wasn’t actioned or that you might have questions about – as they are usually the best point of contact.
At the other side of the spectrum, while the owner of the record does need access to the object and fields – they will receive access to the record itself upon becoming the owner. For example, if the org-wide default settings for accounts are set to “Public Read Only”, the Account Owner will still have edit permissions on account records they own – while the other users will only be able to view the account record and value of the fields they have access to.
Additionally, users above the Account Owner in the role hierarchy will be granted access to the record – once again – assuming that they do have object and field access through their profile or permission sets.
Another useful example is a very specific action that, in the Salesforce UI, is reserved for the owner – and that is updating the Forecast Category of an opportunity. While the relationship between the stage and Forecast Category works in a way that one will be predefined once the stage is changed according to the mapping in the org, the Opportunity Owner can update the Forecast Category to a different one directly on the opportunity. The plot twist here is that not even Admins can do this directly.
If needed, I use either Salesforce Inspector or Workbench to get around this limitation when I am not the Opportunity Owner.
Users vs. Queues
This is an important distinction when discussing record ownership – as when a queue owns a record in Salesforce, it generally means a user did not yet pick it up. In most scenarios, a queue is only a temporary owner – until someone takes over the record either manually or through automation. So, in the end, it will still be a user that is responsible for that record.
Salesforce Queues are records of the Group object, and Queue Members are Group Members. This is crucial to note when working with this functionality, as you will end up with significantly more than one queue depending on the implementations they’re being used for. The queues can easily be identified through the following SOQL query:
SELECT Name, Id FROM Group WHERE Type = ‘Queue’
As objects, such as the account we used in the example above, cannot be owned by queues – let’s switch gears and look at the Leads instead. They not only can be owned by either users or queues but – as you might already know – have their own Lead Assignment Rules, which can be set to define the Lead Ownership based on criteria. When creating a queue, you will have a list of objects to select from as needed.
Queue Members can be added directly by editing a queue, or from the Queue Membership related list on the user record. Unlike users, queues can be deleted if they are no longer used.
In our example, when a lead is owned by a queue – any of the queue members can assign it to themselves and start working on it. Additionally, all queue members can easily be notified when a new lead comes in to ensure immediate action is taken.
This difference in record ownership can also be used in formulas. One, which I find very handy to have, especially for business users who do their own reporting – is a way to tell if the record is owned by a user or a queue using the prefix.
IF(BEGINS(OwnerId, "00G","Queue","User"))
If you’d like to learn more, don’t forget to read the following articles:
- Everything You Need to Know About Salesforce Queues
- Salesforce Lead Assignment Rules Best Practices and Tricks
Ownership Changes
Sometimes record owners have to be changed ad hoc. While usually, the operations teams will re-distribute the high volumes – the owners themselves can also tackle the change for one of their records if needed.
A single account, let’s say, can be transferred either by the Account Owner or any user above them in the hierarchy – be it the role or territory, depending on what is being used in the organization. However, transferring multiple accounts will require not only edit access on the records but also the Transfer Record system permission.
One particularity about transferring records you should pay attention to when defining the permissions is certainly who will be updating records owned by users that left the company. The permission can be enabled on the User Interface page within Setup. It can then be found and assigned to a permission set in the System Permissions. Make sure to take a look at all the permissions needed for each situation and object here.
Summary
All in all, regardless of your business processes, chances are that you and your team leverage record ownership for a variety of tasks as well as permissions – so this is one aspect that always has to be on point to avoid confusion.
Additionally, alongside your admin team, your Salesforce users should be aware of what happens and what is expected of them when they own an account, lead, or why not a custom object record – enablement is key!