Event and Task Access Control Mechanism

Recently one of our org user reported an issue where they were unable to edit an event record showing on the opportunity activity timeline, despite being granted read/write access as a team member on that opportunity record.

To investigate the root cause of the issue, I began by examining the organization-wide default (OWD) settings for events. However, I soon realized that there is no separate OWD setting specifically for the Event object or the Task object. Instead, the OWD configuration for these objects is combined under the ‘Activity‘ category. It was set to Controlled by Parent for the Activity. So Ideally user should have been able to make edits since they had the appropriate editing permissions on the Opportunity; however, this was not the case.

Further I checked two fields on the Event object – whoId and whatId here is how these two field functions –

The “WhoId” field represents the relationship with the contact or lead associated with the event. The parent object can be either a Contact or a Lead.

The WhatId field on the Event object represents the relationship with another object that is not a Contact or Lead. It’s typically used to associate an event with an object like an Opportunity, Account, Case, or any other custom object.

The activity (event) record access is derived primarily from the “WhoId” field for personal events and the “WhatId” field for other events.
Sharing settings and permissions related to the associated Contact or Lead drive access to personal events. For other events (not associated with contacts or leads, e.g., related to opportunities, accounts, or custom objects), sharing is determined by the “WhatId” field.

Upon reviewing the “WhoId” and “WhatId” of the event record the user attempted to edit, I discovered it was associated with a Contact record, with the “WhatId” being the Opportunity record ID. If both fields are populated on the event, access to the record is determined by the “WhoId” field. Consequently, I verified whether the user had edit access to the Contact record and found the user had read-only access and not edit access. Now I was convinced that because the user lacked edit rights on the parent Contact record, they were unable to edit the Event record.

✅ Granting edit access to the contact record allowed the user to edit the event record.

⚒️ Let’s delve deeper into the Activity Access Control Mechanism

Salesforce is a highly secure and robust platform that provides granular control over data access and sharing. One of the critical aspects of data management in Salesforce is the ability to control record-level access to various types of records, including events and tasks. This level of control ensures that users have access to only the information they need to perform their job duties, maintaining data integrity and privacy.

Activities : The Event and Task objects are categorized under Activities within the sharing settings. When you access the organization-wide defaults (OWDs) page, you won’t find separate entries for the standard Event and Task objects. If you do come across individual entries for Event or Task, it likely refers to custom objects you’ve created in your Salesforce org, rather than the out-of-the-box standard objects provided by Salesforce.

☀︎ Organization-Wide Defaults for Events and Tasks

Salesforce provides organization-wide defaults (OWDs) that control the default behavior for record visibility and access. OWDs can be set for various objects, including events and tasks.

The organization-wide default settings for events and tasks can be configured from the Sharing Settings section in Salesforce Setup. There are two possible settings for OWDs:

1. Controlled by Parent: This setting inherits the sharing settings from the parent record (such as an contact, lead, account, opportunity, or case) to which the event or task is associated. If an event or task is not associated with a parent record, the default internal access level is applied.
2. Private: This setting makes events and tasks private, meaning that only the record owner and users with specific sharing rules can access the records.

The behavior of the ‘Private‘ organization-wide default (OWD) setting for activities, such as events and tasks, differs slightly from how it functions for other objects.

When the organization-wide default (OWD) for activities, such as events and tasks, is set to ‘Private,’ the following access rules apply:

Only the activity owner, and users above the activity owner in the role hierarchy, can edit and delete the activity, users with read access to the record to which the activity is associated can view and report on the activity.

If you share an account record with other users, all the associated activities (events and tasks) related to that account will become visible to those users, even if the organization-wide default for activities is set to ‘Private.

So in true sense setting Private still means its Controlled by Parent for read access.

For edit access if the OWD is Private you wont be able to edit even if you have edit rights on the parent record.

When the organization-wide default (OWD) for activities (events and tasks) is set to ‘Controlled by Parent,’ your ability to edit those activities is determined by the edit permissions you have on the associated parent record. If you have edit access to the parent record, such as an Account, Contact, Lead, Opportunity, Case, etc then you will also be granted edit rights for any related activities linked to that parent record.

Activity (Event, Task) object cannot be shared by Sharing rule and this object doesn’t have Sharing table at all.

When creating a new object in Salesforce, you have the option to enable or disable the ability to associate activities (such as events and tasks) with records of that object type. This setting is determined during the object creation process by selecting or deselecting the ‘Allow Activities’ checkbox. If this option is selected, users will be able to create and associate events and tasks with records of that particular object. However, if the ‘Allow Activities’ option is not enabled, events and tasks cannot be linked to records of that object type.

Having the “Edit Event” and “Edit Task” permissions is a prerequisite for creating, editing, and deleting events/tasks. You can locate these permissions in the system permission section of a profile or permission set.

⅀ Summary

Controlling access to events and tasks in Salesforce is a critical aspect of data security and teamwork enablement. The access control mechanism for these activity records is nuanced and governed by several factors, including organization-wide defaults (OWDs), sharing settings, and object relationships.

The key points to understand are:

1) Events and tasks are categorized under the “Activities” section in sharing settings, without individual entries.

2) The OWD for activities can be set to “Controlled by Parent” or “Private,” each with distinct implications for read and edit access.

3) Record access is primarily derived from the “WhoId” (for personal events) and “WhatId” (for other events) fields, determining the parent object driving permissions.

4) When both “WhoId” and “WhatId” are populated, the “WhoId” takes precedence in controlling access.

5) The “Private” OWD allows read access based on the parent record but restricts edit access, even if the parent grants edit rights.

6) Edit access requires read/write permissions on the parent object when the OWD is “Controlled by Parent.”

7) Sharing rules cannot be created for events and tasks directly.

8) The ability to associate activities with an object is determined during object creation via the “Allow Activities” setting.

By understanding these nuances, you can effectively configure access controls to balance data security and collaboration needs for events and tasks. Regular monitoring, auditing, and user training are recommended to ensure proper implementation and adherence to organizational policies and best practices.

Tips for Scaling Salesforce Sharing Configuration for Large Data Volumes