Trigger Configuration

Purpose

Triggers (also known as a business rules) are configurable automation executed in CGR based on predefined parameters and conditions. Triggers form the backend of application configurability, enabling workflow automation and escalation processes. They can be activated when a user performs a save action against a record, including creation, updates, links and deletion. 

Well-configured triggers enhance accountability by driving workflow automation, ensuring users are notified of important changes and updates. 

Important Notes 

• Only system administrators configure triggers.  
• Once the trigger has been saved, the module where the trigger is on can't be changed. 
• Triggers can’t be deleted, only deactivated. 

Step-by-Step Guide To Create a Trigger 

1. Navigate to the Desired Module 
   
   
   
   
   
2. Click ‘Add’ to Create a New Trigger 
   
   
   
   
   
   
3. Complete the Trigger Form:
   
   

   Field	Description
   Title	Provide a descriptive name for the trigger.
   	Event	Description
   Event Selection	After Create	Executes after a record is created, useful for notifying stakeholders about new records (e.g. incidents, complaints, or hazards).
   	After Destroy	Executes when a record is deleted, allowing notifications to be sent to administrators.
   	After Save	Executes whenever a record is saved (created, updated, or deleted).
   	After Update	Executes only when a record is updated (not when created).
   	Before Create	Executes before a record is created, useful for setting default field values.
   	Before Save	Executes before a record is saved, including creation, updates, or deletions.
   	Before Update	Executes before a record is updated.
   	Daily	Runs daily as a background job, useful for status updates based on a date (e.g. moving a record to Pending Review when the review date has passed).
   	Triggered Event	Executes another trigger, useful for linked actions (e.g. closing related actions when a record is closed).
   Priority	Triggers can also be assigned priority levels to determine execution order. Set the applicable execution priority (default: Average), Highest – runs at first one the trigger was hit, lowest – trigger runs at last.
   Enable/ Disable	Choose whether the trigger is active.
   Field Execution (Optional)	Define if the trigger should execute based on a specific field update (e.g. Status change from Draft to Pending Review).
   Forking (Optional)	This only available for daily triggers. Enable forking with caution, as this can result in duplicate records if misconfigured.

   
   
   
4. Save the Trigger.
   
   
   
   Once all parameters are set, save the trigger to finalise the configuration. 
   
   
   
5. Set up your conditions when the trigger should run. See below the different condition types.
   Note: This runs on a ‘AND’ basis only. Every condition added needs to equal true for the trigger to pass the gate. 
   • Compare a Field to a Value: The list of field options is pre-populated based on the fields on the core type in the system. Select from the dropdown your necessary fields. 
   • Compare a field to another field: The list of field options is pre-populated based on the fields on the core type in the system. You can compare two field value against each other. 
   • All Related items are closed or has no related items: This condition type will return true if 1. No action is linked to the item OR 2. All Actions are in a ‘closed’ state. You have the option to invert the result/condition. 
   • Has one or more related items: This condition type will return true if at least one related item exists. This means the item has one or more linked records via the selected relationship (e.g. Actions, Risks, Controls). If no related items are present, the condition will return false. You have the option to invert the result/condition. 
   • All required columns are filled: This condition is specific to audits. It returns true when all fields marked as required within the audit record have been completed. 
     
     
6. Select what effect or activity should occur if the trigger is activated. You can define this on the ‘Effects’ sub-panel or Triggered Notifications. 
   
   Note: Depending on if you select a ‘Before ...’ or ‘After ...’ event, the sub-panel you use differs. ‘Before ...’ can change values of field, ‘After ...’ can send notifications, define an activity to be added to the activity stream or trigger an event. 
   
   Effects: 
   • Set a field to a value: You can select the field and chose a value from the record or use the pointer to point to the value your record should contain, based on another field or record.  
   • Clear a field: Clear the value of a selected field.  
   • Add a value to a field: You can add a number or duration to number or date fields.  
   • Subtract a value from a field: You can subtract a value from a field.  
     
     

• Activities: Select a ‘Field’ and add a default note. This will show in the ‘Activity Stream’. 
• Triggered Events: Select a ‘Triggered Event’ that should be run once the trigger is being activated. Also select a ‘related item’ where the ‘Triggered Event’ should run on. 
• Triggered Notifications: Create a notification that should be sent immediately once the trigger is activated. The notification can be configured similarly to the Email Notifications 

Example

Scenario: Use case: An Action has become Overdue and all linked Risks need to be moved to ‘Review Required’ as there is a potential breach and the related Risks may occur due to this. 

A Triggered Event trigger type needs to be set up on the Risk core type, this is what the Action trigger is going to point to.

Create Triggered Event: 

1. Select target core type (Risk in this case) and ‘Add’ new trigger. 
   1. Title: Choose a title that refers to the source module that will cause the Triggered Event to run.  
   2. Event: Triggered Event 
   3. Priority: Average 
   4. Fields: Not applicable 
   5. Notes: Not applicable 
   6. Enabled: Leave ticked 
      
      
2. Conditions
   1. Add conditions that ensure that only the correct Risks are modified.
      
       
      
      
      
3. Effects
   1. Set the Effect to change the Risk to ‘Review Required’
      
      
4. Create After Update Trigger (Action) - Select source core type (Action in this case) and ‘Add’ new trigger 
   1. Title: Choose a title that is descriptive to what the trigger is doing, and what the target module is 
   2. Event: ‘After X' In this scenario, select ‘After Update’, however it will depend on when you want it to run.  
   3. Priority: Average, unless you have multiple Triggered Events that are going to run at the same time and reliant on each other.  
   4. Fields: Status  
   5. Notes: Not applicable 
   6. Enabled: Leave Ticked 
      
      
5. Conditions 
   1. As per all triggers, select the conditions for the trigger to occur 
      
      
6. Navigate to ‘Triggered Events’ subpanel, select ‘Add’. 
   
   
7. Select the Triggered Event that was created (on the risk). 
   
   
8. Related Items: 
   1. This section allows you to navigate to the related. You can reach Items through relations if required. But in this scenario, the relation will be ‘Risks’. 
      1. Parent Risks will only target the Risk that is in the ‘Primary’ field of an action. 
      2. Risks will target all risks that are related to the action (primary and secondary). 
         
         
         
         
         
         
         
9. Select ‘Save’. 

Common Issues & Troubleshooting

Trigger Not Executing? 

Review the ‘Notices’ page in the admin section to identify which triggers have been executed.  

• Ensure the trigger is enabled. 
• Check that the correct event type is selected. 
• Verify if the specified fields for execution are correctly set. 
• Confirm that priority settings do not conflict with other triggers.
   

Forking Issues? 

• Review conditions carefully before enabling forking to avoid accidental duplication. 
• If unexpected duplicates appear, disable forking and reassess trigger conditions.