CAEP Hub Trigger Overview

Triggers in CAEP Hub are a lot like the Policy Snippets you’ve probably already used to build policies. Triggers enable you to look for patterns in the SGNL Graph and use the existence (or non-existence) of those patterns in Rules.

If you’ve already built Policy Snippets, the basic concept of Triggers should be very similar. The Trigger Builder itself shares many of the same properties with the Snippet Builder. It’s divided into 3 sections:

  • Nodes - The Objects in the Graph
  • Relationships - Relationships between Objects
  • Conditions - Any constraints/conditions you might want to put on those objects

One of the more significant differences between Triggers and Policy Snippets is that you do not have any Request context, meaning that there is no need to associate the nodes or conditions with anything in an inbound request. Triggers will be matched any time any set of nodes, relationships, and conditions start matching or no longer match (depending on your Rule configuration).

Triggers are processed when ingestion of new data into the graph completes, so bear in mind that if you need an extremely low-latency trigger, you’ll want to ensure that the synchronization frequency for the underlying data is sufficiently quick to make these updates.

Creating your First Trigger

Starting with a simple trigger, we’ll assume you’ve already integrated Entra ID into SGNL as a System of Record, and you want to fire a set of Rules/Actions based on a user becoming Disabled.

  1. From the Nav, select CAEP Hub, then Triggers, and then give the Trigger a Name and optionally a Description
  2. From the Nodes, select Entra ID User
  3. In Conditions, select the accountEnabled attribute and select the operator as Equal To and in the value, type false

That’s it. You’re now able to use this trigger inside of a CAEP Hub Rule, to start taking action on Entra ID Users who are disabled.

More Complex Triggers

Going beyond this simple trigger, you might want to include many nodes, relationships, and even conditions into a Trigger. Let’s take the above a step further and assume you’ve also integrated ServiceNow ITSM into SGNL. In this case, you might want to create a Rule that looks for when an Entra ID User has an Approve Change Request in ServiceNow that has been Closed.

  1. Create a Trigger as before, giving it a Name and optionally a Description
  2. From Nodes, select ServiceNow User and ChangeRequest, and select Entra ID User
  3. In Relationships, Select the SameAs relationship between Entra ID User and ServiceNow User, then Select the AssignedTo relationship between the ServiceNow User and Change
  4. In Conditions, select the ‘active’ attribute on the ServiceNow Change, specify the operator as Equal To and specify the value as false
  5. You might have additional business logic to apply in here, say a certain priority or approval state, or even look further into attached CMDB and Configuration Items that might exist - feel free to create additional conditions for those as you see fit

With all triggers, but the particularly the more complex triggers such as the one above, there are a few things to consider:

  • The first time you add a trigger to a rule, it’s going to look at all the existing examples of that trigger in the graph – if you’re starting from a relatively clean slate, you may see no actions fire the first time, however if you have many examples of that trigger in the graph already, you may see many actions fire the first time – this may or may not be disireable.
  • SGNL uses the uniqueId of every node that’s added to build a compound Id for the result set, what this means is that every permutation of the trigger will trigger the same set of actions – as an example, using the Complex Trigger above as the reference point:
    • If you have one Entra ID User (ID: 1) that has a SameAs relationship with two distinct ServiceNow Users (IDs: 2 and 3)
    • Those two ServiceNow Users are assigned to two changes each (IDs: 4,5 and 6,7) which have active set to false
    • You’ll have 4 distinct permutations of that trigger, i.e.
      • 1-2-4
      • 1-2-5
      • 1-3-6
      • 1-3-7
    • This will mean that any Rule that contains this trigger will fire all included Actions 4 times (one for each permutation)

Attributes as Parameters

Under the covers, SGNL adds a set of attributes to return as part of the trigger (similar to a SELECT statement in SQL). We do this from the moment the trigger is created with only the Unique ID of each of the Nodes, but as you start to use attributes of nodes in parameters in Rules, we extend that statement. You can have up to 25 attributes associated with any trigger and can modify that set of attributes from within ‘Available Parameters’ in the Trigger Builder.

Parameters are used only for Action parameterization and have no bearing on the Condition statements that you write in a Trigger, so there’s no need to include Parameters for anything other than the attributes you’re going to use in Actions. For the most part, SGNL will take care of managing these parameters for you.