5.1.16. Triggers and Automation

Triggers and automation rules modify document properties based on predefined conditions and actions. They can be very beneficial for implementation of budget and security policies, and for tailoring efficient workflows.

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 desired outcome
4. Avoid conflicting triggers or automation
   

Working with triggers & automation

Triggers and Automation rules are handled in the Administration Interface under each account and office (see image). Thereby rules can be set up for an entire organization or a specific office within the organization.
On the Triggers & Automations pages 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 in a separate list. Only rules from the Inactive list may be deleted.

Triggers run when a document is added or printed and execute when a predefined set of conditions are met, while automations run every 15 minutes and execute if conditions are met. Rules are run, and possibly executed, in a sequential cycle according to the order defined in the Administration Interface. 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 executes as expected with less requirements for detailed ordering of rules.

Default rules

Certain SAFEQ Cloud functionality are implemented as default rules when a new account is created, so the customer is free to edit it as they see fit. For example, an automation will define print jobs as expired after 32 hours. It is recommended that default rules are not deactivated or deleted.

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 refers to 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.

In the end of this section are reference lists with all conditions and actions, as well as field operators and values.

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 – so establishing good practices from the beginning is advisable.

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 the admin (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.
Descriptive names facilitate a good overview of rules, and it is worthwhile to spend the extra seconds to consider a proper name.

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

Something you may need to watch out for are triggers that undo or modify an action that was contained in another trigger.
Consider an example where you want all print by guests to be in black&white. A 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 power point files to be printed in color. Consequently, if a guest prints a power point 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 power point files form non-guests are set to color.

Consider if automation only run 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 satisfy 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 than 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

Condition	Operators	Values
User Assign actions to either employees or guest users	Is Is not	(authenticated) User is successfully authenticated in a designated authentication provider. Non-authenticated can be used for assigning rights to guest user
User name Assign actions to specific users	Is Is not Contains Does not Contain	[text input] Text is (part of) the user name
User group Assign actions to specific user groups	Is Is not Contains Does not contain	[text input] Text is (part of) the group name
Document status Assign actions to documents at a specific time during the print flow	Is Is not Changed Changed from Changed to Changed not from Changed not to	Received Document is added to print queue, but not yet visible to users Ready Document is added to a print queue and ready to be printed, meaning it is accepted, stored and possibly converted Printed Document is successfully printed Deleted Document is deleted from storage, but has not necessarily been printed Expired Document has been deleted from storage due to expiration of designated retention period Failed Print job failed to print document
Document name Assign actions to specific documents	Is Is not Contains Does not contain	[text input] Text is (part of) the document name
Document type Assign actions to certain types of documents	Is Is not	Unknown The file type is not recognized and will result in a conversion error PDF PS PCLXL
Document attribute Assign actions is a document has certain attributes	Is Is not	Color Black & white Duplex long side Duplex short side Simplex
Hours since document ready Assign action within a certain time after the document state changed to “ready”	Is Is not Greater Than Not greater than Not less than	[number input] Number defines whole hours (integer)
Input port Assign actions to documents sent from known or unknown input ports	Is Is not	(Empty) Documents sent via IPP or API can have a designated input port that is not specified in the Administration Interface, in which case the port is empty (Listed input ports) Input ports set up in the Administrator Interface is individually listed
Input port name Assign actions to documents received from specific input ports (print queues)	Is Is not Contains Does not contain	[text input] Text is (part of) Input port (print queue) name
Input port type Assign actions to documents from either a push or pull queue	Is Is not	Pull queue Follow-me print Push queue Direct print
Output port Assign actions to documents that are not associated with any output port (for example a printer)	Is Is not	(Empty) Push print jobs can have a designated output port that is not specified in the Administration Interface (Listed output ports) Output ports set up in the Administrator Interface is individually listed
Output port name Assign actions to print jobs assigned to specific output ports (for example printers)	Is Is not Contains Does not contain	[text input] Text is (part of) output port (for example printer) name
Output port type Assign actions to print jobs assigned to either a physical printer or a dummy	Is Is not	Dummy Output port is a dummy intended for other purposes than physical printing Printer Output port is a physical printer
Output port address Assign actions to print jobs assigned to specific output ports ( for example printers)	Is Is not Contains Does not contain	[text input] Text is (part of) output port address in IP-format

Action	Values
Output document Output the document, for example by printing	(associated output port) The specific output port the document is already associated with (Listed output ports) Output ports that are added in Administration Interface is shown as individual entries in the list of possible values
Delete document Delete the document from storage	-
Set document attribute Set a specific document attribute	Color Black & white Duplex long side Duplex short side Simplex
Store document Store document in storage	(Default storage) Default storage according to storage service settings.
Assign document Assign the document to the specified user	(Alias) Check Users section for this feature description [text input] Type the target username

Template parameters

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

Parameter	Value
{{username}}	Name of the user
{{userotp}}	Value of one-time password of the user
{{shortid}}	Value of short ID field of the user
{{documentname}}	Title of the document submitted to trigger chain
{{inputportname}}	Name of t he input port through which the document was sent
{{outputportname}}	Name of the printer to which the document was sent for printing

Copyright © 2023 Y Soft