Salesforce Security Guide
jNewer Version Available
Lead Data Export Policy Migration Example
| Available in: Salesforce Classic and Lightning Experience |
| Available in: Enterprise, Unlimited, and
Developer Editions Requires Salesforce Shield or Salesforce Event Monitoring add-on subscriptions. |
Here’s a summary of what we’ve decided so far.
- Create two enhanced policies, one based on ReportEvent and the other on ApiEvent.
- Add conditions to the ReportEvent policy using the QueriedEntities and RowsProcessed fields.
- Add conditions to the ApiEvent policy using the QueriedEntities, ElapsedTime, and RowsProcessed fields.
- Use Condition Builder to create the policy, along with showing the Apex code.
This is the Apex code for the legacy policy that we’re migrating.
- QueriedEntities Equals Lead
- RowsProcessed Greater than 2000
On the actions page, specify the same actions as in your legacy policy.
The steps to create the ApiEvent policy are similar, except we use condition logic. Remember that the legacy policy monitors lead exports when either the rows processed are greater than 2,000 or the elapsed time is greater than 1,000. Here's how to implement this logic in Condition Builder.
You’re done!
And here’s the Apex code for the ApiEvent enhanced policy.
The preceding example shows how elegant and natural the Apex code for enhanced policies is. For example, here’s the legacy way to get the number of rows processed.
Here’s the enhanced policy code in which you can get the required values directly from the event object without typecasting the field values.
Much better and easier to read! For completeness, here’s the Apex code for the ReportEvent policy.
Consolidate Apex Classes Example
Did you notice that the previous two Apex classes for the new Lead Data Export enhanced policies are similar? The main difference is that one policy casts the sObject to ReportEvent and the other to ApiEvent. Let’s change our use case a bit to show how to create a single Apex class that handles multiple event objects. In this case, we remove the condition of checking for elapsed time in the ApiEvent. Now the two policies monitor the same fields of their respective event objects: RowsProcessed and QueriedEntities.
Here’s an example of the "consolidated" Apex class.
The preceding example shows how the Apex code for a policy that handles multiple event objects uses implicit typecasting, branching logic, and event error cases with the switch statement. Also, it’s easy to update this code to handle a new event object or use case.
Expand the Lead Data Export Example with New Use Cases
Let’s say that you’ve created a custom report type in your org that’s based on leads and other objects, such as campaigns. You want to enforce your enhanced policy on this report type, too. In this case, the QueriedEntities field contains a comma-separated list of the objects that the custom report type is based on, such as Lead,Campaign,MyOtherObject. To ensure that the enhanced policy triggers on this custom report type, use the contains() method to check for Lead in the QueriedEntities value rather than equals(). For example:
Next, imagine that you have a custom object HRCase__c that you want to monitor in addition to leads. Add a condition on the QueriedEntities field. For example:
So far we’ve used the ApiEvent and ReportEvent event objects to monitor API queries and report operations. But users can also use list views to view or export org data. Sounds like a job for the ListViewEvent event object! To update the Apex code, add a switch case.