How To

Populate the WhoCount on an Event using the Wait Element in Visual Workflow

If you have a Salesforce org that allows users to relate multiple contacts to tasks and events, at some point, you may have a requirement to show the number of contacts associated to a given event.

Let’s take a few minutes to talk about the structure of events in Salesforce.

For Salesforce orgs that do not have the shared events featured enabled, the contact or lead associated to the event in the Name field is known as the WhoId.

Event.JPG

When Shared Activities are enabled in the Org, the WhoId of the event is the primary contact or lead on the event. In the example below, Sean Forbes is the primary contact on the event and is identified as the WhoId.

WhoId-SharedActivities.JPG

To determine the total number of contacts and leads associated to the event, you need to look at the event’s WhoCount field. This field is available to Salesforce orgs that have Shared Activities enabled. The WhoCount represents the count from the related EventRelations junction object pertaining to the WhoId.

When the Shared Activities feature is enabled, the relationship between the event and a lead or contact is stored in a derived object of the EventRelations object called the EventWhoRelations object. Continuing with the example from above, the contacts and leads associated to the event (00Uj0000006DMX8EAO) are stored as individual EventWhoRelation records with the contact’s or lead’s 18 character SFDC ID appearing in the RelationId field.

EventWhoRelations.JPG

If we count the EventWhoRelations records tied to the event, we come up with 7, which matches the WhoCount (# of Attendees) of the event.

EventWhoCountMatchesWhoID.JPG

Here are a few lessons learned from implementing this use case:

  • EventWhoRelations records are created shortly after the event for the primary contact is created. If you try and retrieve the WhoCount for the event using process builder after record creation, it will always return a WhoCount of 1, as the related event records have not been created.
  • The wait visual flow element will wait for one or more defined events to occur, which allows you to automate processes that require a waiting period. For more information on the Wait Flow Element, visit Salesforce Help & Training.
  • Provide descriptions, where provided, in Salesforce. This may be tedious step, I know, but your future self will thank you when you are trying to remember what you configured or assist other/future admins when troubleshooting or enhancing what was built. This includes noting the data stored in a custom field, providing the purpose of a process builder, etc.
  • For any data actions (fast and record lookup, create, update and delete actions) performed in visual workflow, best practice is to include a flow element to send an email to your Salesforce administrator about the fault.

Flow trick: To getting the Fault connector to appear, either draw the regular connector link to another flow element or connect it to a temporary flow element. Draw the fault connector to the Send Email element. Then, go back and delete the regular connector.

Business Use Case: Addison Dogster is a system administrator at Universal Container. Sammy Sunshine is the Sales Director who would like to see the number of attendees on an event for use in reporting.

Solution: Addison understands that for shared activities, there is interaction in eventrelation junction objects that come into play. She is able to solve this declaratively by creating a custom activity field to store the event’s WhoCount, and a process builder with an autolaunched flow to update the WhoCount on the event.

ProcessBuilderDiagram.JPG

FlowDiagram.JPG

Quick Steps:

1.Create a custom activity field (Customize | Activities | Activity Custom Fields).

WhoCountField.JPG

Best practice tips:

  • Don’t forget to provide a description so you and other/future admins know what this new field is used for.
  • Set the FLS (field level security) for each profile. Only make the field visible and editable for the profiles that need it. Do not just click the “Next” button when you are on the screen.
  • Select the page layout(s) that the new field needs to be added to. By fault, new field is added to the page layout.

2.Update the field position on the event page layout (Customize | Activities | Event Page Layouts). Make the field read only for business users.

EventPageLayout.JPG

3. Create a visual workflow (Create | Workflows & Approvals | Flows). This flow to wait for the creation of the EventRelations records to lookup and update the given event record. This is an autolaunched flow invoked from process builder Update WhoCount on the Event that we will create in Step 4.

UpdateWhoCountonEvent-Flow.JPG

A. We need to create 3 variables that will be used in the visual workflow per the screenshots below, which will store the event’s SFDC ID, the event’s modified date/time and event’s WhoCount.

Best practice tip: Don’t forget to provide a description so you and other/future admins know what these variables are used for.

varEventId.JPG

varEventModifiedDateTime.jpg

varWhoCount.JPG

B. Create a Wait Element that pause the visual workflow for 0.005 hours or half a minute. (Note: You can only set the unit to hours or days). Once it is 0.005hrs from the date/time stored in the variable varModifiedDateTime (which will be the Last Modified Date/Time of the event record passed in the Process Builder built in Step 4), it will then process with the flow.

FlowUpdateWhoCountonEvent-Wait.JPG

FlowUpdateWhoCountonEvent-Wait1.JPG

Best practice tip: Don’t forget to provide a description so you and other/future admins know what the wait element is supposed to do.

C. Create a Record Lookup element that will lookup the Event object, where the ActivityID matches the varEventID. Take the value of the WhoCount from the event to update the variable varWhoCount. Note: We will be passing the varEventID variable from the Process Builder to be created in Step 4.

FlowUpdateWhoCountonEvent-RecordLookup

FlowUpdateWhoCountonEvent-RecordLookup1.JPG

Best practice tip: Don’t forget to provide a description so you and other/future admins know what the record lookup is supposed to do.

D. Connect the Wait flow element to the Record Lookup flow element with the Wait connector.

WaitRouting

E. Create a Record Update flow element to update the # of Attendees (i.e. WhoCount) field on the Event with the value in the variable varWhoCount.

FlowUpdateWhoCountonEvent-RecordUpdate.JPG

FlowUpdateWhoCountonEvent-RecordUpdate1.JPG

Best practice tip: Don’t forget to provide a description so you and other/future admins know what the record update is supposed to do.

F. As a best practice, where there is a DML action (fast or record create, update, delete or lookup action) in a flow, you should also include notification of a flow fault.

Refer to my post Using Custom Metadata Type in Visual Workflow Fault Emails for configuration steps.

G. Click on the “Save” button. Name your visual flow, description and ensure the type is “Autolaunched Flow”. Click on the “Ok” button.

Best practice tip: Don’t forget to provide a description so you and other/future admins know what this visual flow is used for, where it is invoked from.

FlowUpdateWhoCountonEvent-FlowProperties.JPG

H. Click the “Close” button.

I. On the flows detail screen, activate the flow.

FlowUpdateWhoCountonEvent-Activate.JPG

4. Lastly, we will create the process builder that autolaunches the visualflow created in Step 3 (Create | Workflows & Approvals | Process Builder).

ProcessBuilderDiagram

A. Provide the process name and description.

ProcessBuilder-UpdateWhoCount-Properties.JPG

B. Select Event as the object and set the process to start “when a record is created or edited”.

ProcessBuilder-UpdateWhoCount-EventObject.JPG

C. For the criteria node, we’re going to name it “Always execute” and set the criteria to “No criteria – just execute the actions!”

ProcessBuilder-UpdateWhoCount-CriteriaNode.JPG

D. Add a new action under Immediate Actions. Select to launch a flow. We’re going to name the action “InvokeFlowUpdateWhoCountonanEvent”. Locate the flow by its API name. Set the flow variables:

  • varEventID Reference [Event].Id
  • varEventModifiedDateTime Reference [Event].LastModifiedDate

ProcessBuilder-UpdateWhoCount-ImmediateAction.JPG

E. Click on the Activate button in the upper right hand corner.

ProcessBuilder-UpdateWhoCount-Activate

F. Click the Save button.

G. Click the Activate button in the upper right hand corner. Click the “Ok” button.

ActivateVersion

That’s it. Congrats, you’ve implemented the solution!

Now, before you deploy the changes to Production, you need to test your configuration changes.

1.Login as a user and create a event at least one additional contact or a lead.

2.Go to Flows screen and under the Paused and Waiting Interviews section, you will see the wait entry for the Update WhoCount on the Event flow.

PausedandWaitingInterviews.JPG

3. Wait about half a minute, refresh the event detail record.

4. Confirm that the # of Attendees field is updated with the correct WhoCount value. Note: This can be validated by querying the WhoCount on the event.

EventRecord.JPG

5. Now, create an event with only one contact or lead. Confirm the # of Attendees is correctly shown.

Deployment Notes/Tips:

  • The new custom activity field, visual flow and process builder can be deployed to Production in a change set.
  • The field level security for the custom activity field will need to be manually updated post deployment. I would caution against adding the related profiles in the changeset for deployment as the results of deploying a profile are not reliable. If you have a tool like Snapshot by Dreamfactory, you can use the tool to deploy field permissions.
  • Manually add the custom activity field to the Event page layout.
  • Activate the visual flow and process builder after they are deployed in Production as they are deployed as inactive.