Rules - triggers and automation

Relevant Products

Rules are available in BREEZE MFD PRO PRINT PRO MFP

Triggers and automation rules modify document properties based on predefined conditions and actions. They can be helpful in implementing budget and security policies, and for tailoring efficient workflows.

Triggers run when a document is added or printed, and execute when a predefined set of conditions is met.

Automations run every 15 minutes and execute if conditions are met.

In this section, the triggers & automation features are explained, and these main aspects will be covered:

1. Building condition and action statements

2. Name triggers and automations using descriptive names

3. Reordering triggers and automations to achieve the desired outcome

4. Avoid conflicting triggers or automation

Working with triggers & automation

Triggers and Automation rules are handled in the SAFEQ Cloud Web UI under each account and office. Therefore, you can set up rules for an entire organization or a specific office within the organization.
On the Settings > Rules page, you can search for, add and reorder rules. You can also edit, clone, and deactivate/activate specific triggers/automation. Note that inactive rules are shown at the bottom of the table. Only inactive rules from the list may be deleted.

Rules are run, and possibly executed, in a sequential cycle according to the order defined in the Web UI. Whenever the conditions for a specific rule are met, and an action is executed, the cycle restarts (see flowchart below). This cyclic flow ensures that interdependent rules execute as expected with fewer requirements for detailed ordering of rules.

Default triggers

Certain SAFEQ Cloud functionalities are implemented as default triggers when a new tenant is created.

• Failed workflow – This trigger activates when a scan job hasn't been successfully delivered. For this trigger to function correctly, you must set the email address of the admin user in the trigger actions.
  

  

  
  The admin will receive an email with information about the failure, the error code, and the error message which may help the admin to resolve the problem. For the list of error codes, see Workflow error codes.

• Delete downloaded scans - This trigger activates when a scan job is downloaded from the My documents page.
  

  

  
   It removes the scanned document from My Documents page. If you want to keep the downloaded documents, you should deactivate this trigger.
  

  

  The document is removed even if the browser prompts the user for a download location and the user subsequently cancels the download.

Default rules

Certain SAFEQ Cloud functionalities are implemented as default rules when a new tenant is created.

We recommend that you do not deactivate or delete these default rules.
Note that some default rules, such as Delete expired scan jobs, cannot be deleted or edited.

Delete expired jobs

Marks unprinted jobs as expired and deletes them after 32 hours.

Delete expired scan jobs

This rule sets the maximum retention period in for scan documents to 168 hours (7 days).

To decrease this retention period and ensure the correct display for end users, clone the rule and include the following conditions:

• Hours since document created

• Job type Is Scan

If your cloned rule specifies a retention period longer than 7 days, the default rule will override it.

Building condition and action statements

Both Triggers and Automation consist of condition statements and action statements.

• Condition statements consist of conditions, field operators, and condition values (these vary depending on the condition selected). Condition statements are essentially ‘if’ statements that return all print jobs that meet the specified criteria.
  For condition statements, the trigger will execute whenever the condition is changed. 'Changed' means any update made to the value, even if the value previously did not exist. For example, the Input Port Name trigger condition will execute even if the Output Port did not exist when a trigger was defined.

• Action statements consist of actions and action values (these vary depending on the condition selected). Some actions will be unambiguous, in which case a value does not apply – for example, the Delete Document action. Action statements define what occurs if all the condition statements are true and the trigger executes. You can think of action statements as ‘then’ statements – if all your conditions are true then perform these actions to update the document or print job.

At the end of this section are reference lists with all conditions and actions, as well as field operators and values (see Conditions and Actions Reference lists below).

Best Practices for triggers & automation

Triggers and automation rules should be carefully designed and arranged to achieve the desired outcome. As more rules are added over time, it becomes more critical to manage the collection – therefore we recommend establishing good practices from the beginning.

Choosing a descriptive name

While triggers and automation rules can be a huge benefit, they can be tedious to maintain if not named appropriately. Choose a descriptive name that makes it easy for you (and any future admins) to remember what statements are contained in the rule, and to distinguish between different rules.
Consider these three identical triggers with different names.

They all communicate some aspect of the rule, but the first name is clearly superior for introducing what the rule does.

Reordering rules

Rules run in a sequential cycle. Certain rules will have actions that change parameters used as conditions in other rules. To achieve the expected outcome, it is therefore important to consider the order by which rules are run.

Avoiding conflicting rules

You may need to watch out for triggers that undo or modify an action contained in another trigger.
Consider an example where you want all print by guests to be in black&white. Trigger 1 determines all print jobs by guests will be set to black&white. Now consider a Trigger 2 – added for a different purpose – that sets all PowerPoint files to be printed in color. Consequently, if a guest prints a PowerPoint file, the order of triggers will determine the color attribute. One remedy for this situation is to add a condition to Trigger 2 that checks if it is a guest user, so only PowerPoint files from non-guests are set to color.

Consider if automation only runs once

Automations check every 15 minutes to see if their conditions are met. Typically, automation rules are meant to only execute once for each print job or document that satisfies the conditions.
To avoid continuous executions, an automation must include one of the following:

* an action that nullifies at least one of the conditions, or * a condition that can be true only once

If there is no nullifying action or true-only-once condition, the unmodified conditions will continue to be met, and the automation will continue to execute – possibly in an endless loop.

Conditions and Actions Reference lists

Template parameters

Several conditions and actions may accept template parameters enclosed in double curly braces. The following parameters are currently recognized: