Use Process Builder and Flow to easily auto-share task with task creator

We haven't used the standard task object in our org that much, so when one of my users recently complained that they were unable to edit a task that they created and assigned to someone else, I was surprised. For most other objects, the creator automatically has read/write access. But, as in many other ways, the Activity object is special and I discovered that by default, only the user in the 'Assigned To' field has read/write access.

This was a big problem for us, since we had users who were creating tasks for their team, but then once the task record was created, if anything changed, they'd have to get the assigned user to change the task rather than being able to do it themselves. Huge roadblock.

Fortunately, I discovered that you can also control read/write access to the Task through the contact record in the WhoId field. So, if the creator also had read/write access to the contact record in the WhoId field, then they'd be able to edit the task. Phew!

But...how do I make sure that the task creator has read/write capabilities on that contact? And how do I make sure that a contact record is even in the WhoID field on the task?

I decided to tackle the second problem first. I set up a new contact record named 'Sharing Access' in the new account 'Sharing Access Household.' The description on the contact reads, "This contact gives the user read/write access to tasks that they wouldn't have access to edit otherwise, since they are not named in the 'assigned to' field."

Then I tested it. I logged in as a non-admin user, created a task, and assigned it to another user. But before I hit 'save' I put 'Sharing Access' as the contact in the WhoID field (this field displays as 'Name' in the page layout). Then I tried editing the task. This did not work, which was expected. Then I logged out as the non-admin user, went to the Sharing Access contact record and clicked the 'Sharing' button and gave the non-admin user read/write access. When I logged back in, I was able to edit the task. Woohoo!

So, it works if someone manually puts the contact in the WhoID field and they manually share the record with the creator user. But, I didn't want to have to rely on my users remembering to do that each time. So, how do I automate it?

Enter Process Builder and Flow. I had discovered, for another project, that you can use Flow to automatically share a record with a user. So, I create the auto-launched flow: ShareContactWithUser.

Steps to create flow:

First, I create 4 variables: ContactOwnerID, UserIsActive, VarT_ContactID, and VarT_UserID. They are all of data type 'Text' and are available for input and output.

VarT_ContactID and VarT_UserID are both filled in by the process that I'm going to create in a second which launches this flow.

I discovered, through testing, that if you try to manually share a contact record with it's owner you will get an error. So first, I use a lookup element to find the id of the owner of the contact record and store that id in the ContactOwnerID variable. Then I create a decision element to check and make sure that the user id from VarT_UserID isn't the same as the Contact Owner ID.

You also get an error if you try to share a record with an inactive user, so I repeat the process by using another lookup element to retrieve the IsActive field on the Owner's user record, store that in the 'UserIsActive' variable, and then use a decision element to make sure that 'UserIsActive' is true.

So, after all that, if the task creator is not the contact owner AND they are not inactive, then I use the create record element to create a Contact Share record and share the contact with the task record.

So that's it for the flow. I intentionally set it up so that if I want to reuse it from another process to automatically share a contact with a user, it would be pretty easy to do so.

Steps to create process:

Next up, the process. Basically, the way the process, which is triggered when a task record is created or edited, works is that first it checks to see if the task's WhoId field (called Name ID in the screenshot below) is blank. If so, it puts the 'Sharing Access' contact id into that field. If not, it moves onto the next step. Then, it calls the flow we created above to share the contact in the WhoId field with the creator of the task. Both steps have the advanced 'Do you want to execute the actions only when specified changes are made to the record?' field checked in the define criteria diamond.

That's it. Just make sure both the process and the flow are active and your task creators should now retain edit privileges on the tasks they create.

One point of caution - if you want to make sure that only certain types of tasks are shared, or only certain users have access to view/edit certain tasks, you may want to have several Sharing Access contacts, one for each team or department, or exclude certain task creators from triggering the process.

Another option is to create a process to automatically set up a contact record for each of your users, link to it from their user record, and automatically give them edit privileges to that contact (using the flow you created above). Then, in setting up the process mentioned above, instead of changing the WhoID field to the Sharing Access contact when the WhoID field is blank, change the WhoID field to the user's contact. That way, all of the tasks that aren't related to an actual contact will only be editable by the task creator and the person in the 'assigned to' field. The ones that are related to an actual contact would work the way that tasks work currently: anyone who has edit access to the contact would have edit access to the task. This would just ensure that the task creator retains edit rights too.

It's up to you to set it up so that it makes sense for you and your use cases. In our case, this wasn't necessary, and time was a factor, but it's always important to think about security when setting something like this up.