The purpose of the configuration flow in a SightLane Policy Event is to determine whether the details of a standard Transaction Security Event are "of interest" to the organization. For instance, a team may be interested in whether anyone outside the company (like an ex-consultant with an email address outside the corporate domain) logs into the Salesforce org. They are probably not as interested, though, in every one of the hundreds or thousands of logins that occur every day across their user base.
Using the Default Flow
When a policy event is "triggered," it means that SightLane should document the event and execute any responses configured for that monitor. Let's take a look at the default SightLane Configuration Flow and how it can be used in the decisioning process.
Wow! What a beauty! :) Rather than create dozens of different flows for you to keep track of, SightLane provides a single overridable Flow that can handle all Transaction Security Policy Events. You are not obligated to use it and can create your own Flows (as you'll discover in the next article), but this is a good starting place for most teams.
The secret sauce to this flow is the decision element, "Evaluate Policy Event." This element inspects an input parameter called "Policy Event," which contains all the details of the Transaction Security Policy event being considered. Once the event's event type is determined, the Flow will take the correct path, according to the logic provided. By adding to the conditions of this decision element, you can focus only on events that you care about. If an event doesn't meet your criteria, it will be ignored.
Once the event's flow logic path is complete, it goes through the "Assign Result" element to populate the Result output parameter. This value goes back to SightLane and tells it how to proceed with its documentation procedures. By default, all event types simply proceed directly to the Result and are assigned a value of True. This means that any Policy Event (remember the Custom Metadata Type from the last article?) that references the default evaluation flow will cause SightLane to document the event. If you do nothing with the evaluation Flow, Sightlane will automatically monitor and document all events referencing the default flow. How easy is that?
The Real Power of Customization
Here's where things get really interesting. What if your decision isn't based purely on information contained in the event itself? What if you need to ask other questions before deciding if the event is meaningful? With the Evaluation Flow, it's no problem!
In the example below, we have extended the default evaluation Flow and customized the logic. This is because the Transaction Security Policy event for user logins does not contain a critical piece of information we need. It does contain the username of the person logging in, but it does not contain their role. With out-of-the (Salesforce) box event management, you can only consider things that are a part of the event data (unless you want to write a whole bunch of Apex).
But with SightLane for Shield, you can add any logic you desire to the evaluation Flow. In the example above, we have added a query to the User object to retrieve extended information about the User that the Transaction Security Policy references. This allows us to make much more sophisticated decisions about the impact of this event on our system. In this case, if the User's role is "consultant", then this is an event we care about and needs to be documented. If it is just a regular internal User, then we can skip it and avoid generating "junk logs" in SightLane.
Conclusion
Evaluation Flows take a little bit of thinking to get your head around. But in return, you have almost unlimited power to investigate Transaction Security Policy events and determine what events may be "red flags" and need more attention. And the best part is, it is all now click-and-configure simple! If you want to chat with us about how to fine-tune your Evaluation Flows, reach out at support@sightlane.com