Workflow Rules

This field identifies the Workflow rule.

Use this field to assign a description to each record.

This field is used to perform typology-based groupings of the workflow rules.

As long as this box has not been checked, the Workflow rule is not likely to be triggered.

The Workflow event type can take the following values :

• Object : the function here is of the object type (record managed in creation, modification, duplication, deletion...mode). Then the event code corresponds to the object code.
• Function entry : the rule is triggered when entering a function of the software. The event code corresponds to the function code (an object coded as XXX corresponds to the GESXXX function, as a consequence, this type of event can also be used for objects).
• Print : a report is launched, and its code can be specified in the event code field.
• End of task: a Workflow is triggered at the end of the batch task, and its code corresponds to the event code (the batch task in question needs to have the box User message checked, otherwise it will not work. a warning message indicates otherwise, yet the entry is not forbidden for all that).
• Task interruption : this workflow rule is triggered when a user decides, from the task monitoring, to interrupt a batch task whose code corresponds to the event code. The user sends an interruption request to the batch server, and the server stops the task. Given the execution context of this event, the triggering possibilities are limited. Indeed :
• the usual environment variables (for instance, GUSER) are not available, only the current record in the [ABR] ABATRQT abbreviation table is.
• only a message can be sent via e-mail (no tracking table can be updated).
• Import/Export : this type of event is triggered at the beginning (and/or end) of the import (and/or export), and the event code makes it possible te specify the template being used.
• Signature : this rule is triggered when signing a former rule, whose code can be given by the event code.
• Manual : this rule is triggered by running through a set of tables described in the data template. This read is triggered via a manual operation which can obviously be launched in batch mode. This is especially useful to trigger the Workflow rules linked with field modifications in the database (the rule runs through the audit tables).
• Miscellaneous : this rule is triggered for particular events identified by a finite list of event codes. These events can either be generic for all software written in Adonix technology (for instance, connection, disconnection...), or they can depend on a function specific to the software being used. The list of the generic events is drawn up in a first documentation appendix, and the list of events specific to each software, in a second documentation appendix.

This field specifies the triggering context, based on the previously defined type :

• for an Object type, the code of the corresponding object is given.
• for a Function entry type, the function code is given.
• for a Printing type, the report code is given.
• for an End of task or Task interruption type, the code of the batch task is given.
• for an Import/Export type, the import/export template being used is given.
• for a Signature type, the code of the rule at the origin of the signature request is given.
• for a Manual type, no code is entered.
• for a Miscellaneous type, the code that identifies the miscellaneous event at the origin of the rule triggering is given.

This field is mandatory only for the event type Miscellaneous. If not entered, the event is triggered in a generic way, remembering that it is always possible to further test the context to be selective (thanks namely to the GFONCTION, GOLDETAT...variables).

Name associated with the code entered in the previous section

This field is used to further define the execution context of the Workflow rule. Depending on the Workflow types, the information entered is different :

• For an Object type, a series of codes is entered to allow the definition of the standard operations (M for Modification, C for Creation...) and those operations specific to an object, if the latter is defined (buttons and menu items) that will trigger the event. An operation code at least is then compulsory.
• For a Signature type, the operation code attached to the answer given in the signature process is entered.
• For an Import/Export type, a list of a maximum of 4 codes specifies whether the rule triggering must occur at the beginning and/or the end, and if it concerns the import and/or export operations.
• In all other cases, this field is not entered.

When modifying the record of a simple object, the workflow can be triggered before updating the tables (this makes it possible to define criteria on the [F] and [M] classes) or at the end of the modification transaction (after updating the tables).

Here it is possible to specify a data template that defines a set of linked tables which need to be available in the Workflow context. In the case of a Manual type event, this code is compulsory to define the execution context; in other cases, it is only used to complete this context.

This field is used to define externally to the rule the allocation rules of the Workflow recipients. It refers to a rule table which defines a list of fields impacted by the allocation criteria of the recipients.

A rule is evaluated when the Workflow is triggered, based on the context, and it returns one or several users defined in the [L]USER local variable table. This makes it possible either to define a list of recipients for a given Workflow or a sequence of recipients in the case of chained rules.

It should be noted that:

• when an allocation rule is defined in a Workflow rule, all the recipients are evaluated based on those criteria defined and stored in the [L]USER table.
• When no allocation rule is defined, but the Workflow rule is of type Signature, the values of [L]USER calculated in the event at the source of the signature (these values are stored in the history) are inherited. Should the need arise to reevaluate the allocation rule of origin (because criteria values may have changed), this allocation rule needs to be reentered into the Workflow rule.

It defines whether a Workflow is going to be triggered on each detail line or only on the header.

This field is not entered, it is only displayed :

• if neither an allocation rule nor a data template have been defined. The type is equal to Line if the Workflow is manual, otherwise it is of the Header type.
• When an allocation rule using a line table is defined, the Workflow is of the Line type.

If no allocation rule has been given, but there is an associated model integrating links (1,N), the field is entered. Then it is possible to choose whether the Workflow will be triggered at line or header level (remembering the fact that the lines can be regrouped to send a notification by group).

This is used to define the line field in the case of a rule where the context integrates header tables and line tables.

This field is used to define grouping criteria by providing a list of expressions (or fields) separated by semicolons. This is useful to group detail lines and thus only trigger one Workflow upon each break on the values defined by these expressions.

This is possible in two cases :

• When a Workflow event uses a data template displaying links (1,N), and the Workflow is of a line type (it runs through all the lines in the selected line table), lines can be grouped together.
• When a Workflow event is of a Manual type, (all read lines can be grouped together in the same manner).

In the case of a Line type Workflow, the conditions can concern either the header or the line, depending on the selection entered here.

These fields allow some supplementary conditions in the form of logical expressions ( Calculation formula) including on-line variables at the moment of the rule execution (containing screen masks or on-line tables, based on the context description...). If these conditions are all true, the message will be sent and/or the trace written in the log file.

It should be noted that, when the context is of type header and lines, it is possible to filter part of the lines linked to a header by defining line conditions so as not to take into account lines for which the condition is wrong. If at least one concerned line remains, and the header conditions are true, the triggering will nevertheless occur

This indicator is used to activate or not the sending of the messages mentioned in the corresponding tab.

This indicator is used to activate the triggering of the actions mentioned in the corresponding tab.

This field is used to define externally to the rule the allocation rules of the Workflow recipients. It refers to a rule table which defines a list of fields impacted by the allocation criteria of the recipients.

A rule is evaluated when the Workflow is triggered, based on the context, and it returns one or several users defined in the [L]USER local variable table. This makes it possible either to define a list of recipients for a given Workflow or a sequence of recipients in the case of chained rules.

It should be noted that:

• when an allocation rule is defined in a Workflow rule, all the recipients are evaluated based on those criteria defined and stored in the [L]USER table.
• When no allocation rule is defined, but the Workflow rule is of type Signature, the values of [L]USER calculated in the event at the source of the signature (these values are stored in the history) are inherited. Should the need arise to reevaluate the allocation rule of origin (because criteria values may have changed), this allocation rule needs to be reentered into the Workflow rule.

This indicator enables an adjustment help to be activated. On execution of a rule and if this option is active, the Workflow engine sends to the screen any evaluation error messages for the conditions, the log and the message.

This field makes it possible to define a logical condition. If the evaluation of this condition returns a wrong value (i.e. null), the recipients line is not concerned by the event.

It should be noted that, in addition to variables related to the event context, the [L]COND variable grid is also available, thus making it possible, for any given line, te refer to the condition of line number N (N being the index).

For instance, if a condition is expressed on the first line of the grid, and, on the second line, the expression not [L]COND(1) is used, it means that the recipients of the second line will be taken into account if the condition of the first line is wrong.

A recipient can be linked to a user code (their details are then searched for in the user record), or a Business Partner (in that case, their details will be entered in the grid to identify on the BP record the concerned recipients).

This information is only entered if the recipient type is a business partner. It refers to the local menu that defines the functions of the contacts in the Business Partner record.

Three values concerning the recipients of the line can be entered here :

• No: they will not be sent any message.
• Yes  : a message will be sent to them as main recipients.
• Copy : a message is sent to them in copy mode.

This flag is used to tell whether the recipients of the line will receive a notification in their planning workbenches, depending on the value entered :

• No : in that case, no notification will be available in the planning workbench.
• Yes  : a notification will be sent to them, it may only be initialled to indicate that the user has read it.
• With signature : this notification needs to be signed by one of the recipients of the line.

Whenever a notification is sent to at least one of the recipient lines, the Approval request tab defines the text that will appear in the approval request, along with the answers that may be brought in case of a signature request.

This field can be used to classify the approval request lines depending on their categories. It features a criterion that can be included in the planning workbench or be used as a filter in one of its tabs.

This field makes it possible to specify how to manage the fact that the recipient identified in the line is absent (in other words, they have defined a delegated user for a period of time covering the moment when the rule has been triggered). If the recipient has specified delegated users With authority, the v alue of this field defines who is the recipient of the notification or message :

• If this field is set to No, only the original recipient mentioned is concerned.
• If it is set to All, the recipient and all the users defined as delegated users to the recipient are concerned.
• If it is set to Cascade, the recipient, their users, and in turn the delegated users to their users etc. are concerned.
• If it is set to First free, the first recipient with no delegated user is concerned.

This field is used to specify the content of the Subject field of the message sent, in the form of a calculated expression that will be evaluated when the event is triggered.

This field is used to define the main content of the message. It is written as free text which includes logical expressions (calculation formula) between two vertical lines that serve as separators. For example, it is possible to write such contents as :

The event which occured on | num$(date$) | generated this sending by | GUSER |.

The calculated expression entered in this field is evaluated, when the event is triggered, for each detail line (in the case of a line-type Workflow with data grouping). Each line thus calculated is integrated into the text body at the location of the |LIG| formula.

This field is used to specify whether the message must be sent locally by the workstation (in MAPI interface), from the server (via SMTP) or equally from one or the other (in that case, a general parameter called TYPMES defines it).

If checked, this box makes it possible to enclose in the message sent an icon containing the context used to remind the record (by double-clicking on it). Note that this only works for a client-server connection.

When an icon to return to Adonix X3 is enclosed to the message body, this field makes it possible to specify a return function different from the function which had triggered the Workflow.

In object Workflow, when creating or modifying a record, this makes it possible, rather than connecting to the default record, to reach a linked record (for instance, the record of the user having created or modified the information which has triggered the Workflow).

If the check box Return icon is checked, this field makes it possible to define the function to which the user will be connected after doucle-clicking on the icon enclosed to the message.

If the return function is of the object type, the function should only be entered if it is different from the source object.

In the case of a Manual Workflow, the function code is compulsory if the return function is enclosed (there cannot be any default value in this case).

This indicator makes it possible to modify the message before sending it : a screen appears to enter the modifications. This is only feasible if the Workflow is triggered in an interactive way (otherwise, the window will not open).

When a Workflow event generates several notifications, this box is used to group the messages created by this event.

There are several notifications if the Workflow is of the "Line" type, or in the case of the special "ANU" event (triggered upon signature cancellation).

Notifications are regrouped together if they present the following common caracteristics :

• the sender
• the server type
• the return context
• the message subject
• the acknowledgement of receipt
• the recipients
• the signer flag

When checked, this box makes it possible to send a message and ask for an acknowledgement of receipt. Note that this request for an acknowledgement of receipt only works if the message is sent from the client workstation, and not from the server.

This box can only be checked if the triggering event corresponds to the end of a batch task.

In that case, if it is checked, the trace file associated with the batch task will be enclosed to the message sent.

This field is used to enclose an attachment to the message by giving a network access path in the form of a calculated expression that will be evaluated when the event is triggered.

With this box checked, for an object-type Workflow, the enclosures to the record can be sent as enclosures to the message.

This field is used, when the All types box is not checked, to define a filter on the type of attachments to the record (miscellaneous table 902) that must be sent with the message.

This box is only entered :

• for an object type workflow
• for which the Attachments box is checked (the attachments to the record are sent in the form of documents associated with the message).

If this box is checked, all categories of attachments to the record which trigger a Workflow are sent as documents associated with the message. Otherwise, the concerned category is entered.

When documents enclosed to a record must be sent as attachments to the message, this field is used to filter the linked documents by their categories (96 local menu).

This field contains an expression evaluated when triggering the Workflow. The result of this evaluation is an alphanumeric chain stored in the [AWS]TEXSUI variable. This value is the one usually presented in the Workflow monitor to qualify the event to be signed.

If this box is checked, the approval request generates a signature process : the table located at the bottom of the screen contains a certain number of possible signature choices.

Whenever the Signature box is checked, it is possible to define a date type expression to specify the date beyond which a delay is considered to happen if the signature did not occur.

The value of the corresponding field is stored in the DATREL field of the AWRKHISSUI approval request table. This field can be processed in the Workflow monitor, in order to define a classification order, an underlining using a particular style (for instance, condition with type date$>=[AWS]DATREL+1). Yet this field can also be processed to perform the follow-up management of those events pending signature, remembering the fact that the [AWS]NBREL field is used to count any created reminders.

This table contains expressions evaluated when the Workflow is triggered. These variables :

• are stored in the Workflow history (VALCTX1 to VALCTX15 variables).
• can be used within the signature context (CTX(1) to CTX(15) variable table) associated with the source event, or to a Workflow event following the signature.

These variables are of interest because they make it possible to transmit information which is not located in the tables of origin of the triggering context, and which, as a consequence, is not automatically transmitted from an event upon signature or when the next event occurs. As a matter of fact, the object tables, or the tables of the allocation rules, are automatically transmitted; on the other hand, the following are not trransmitted :

• global variables (for instance, the GUSER, GFONCTION, GABREV, CLEOBJ variables, which respectively define the current user, the current function, the object code and the current key upon triggering an object Workflow).
• variables linked to the on-line screens
• expressions such as date$, time$... which qualify the triggering context

These are the types of variables which it is interesting to transmit via the context. Yet, it is also interesting to define in the context variables otherwise transmitted within the context, simply to be able to display them in the Workflow monitor.

This field refers to the miscellaneous table no. 54, which defines the possible choices upon signature (for instance Validation, Refusal). In the signature planning workbench, right-clicking on the line to be signed will make it possible to suggest, among the choices coming from this list, those choices for which the condition has been met.

This operation code, defined by the miscellaneous table 55, represents the code that qualifies the completed signature. It corresponds to the operation code used in a Signature type event further to the signed event. It should be noted that several lines can bear the same operation code.

This code is not stored in the Workflow history further to the signature. Indeed the value of the Answer field which does not authorize homonyms between the various lines, is the one to be stored).

This column contains a logical expression evaluated at the moment of signature. If the condition is met, the answer defined on the line is suggested among the possible choices. This is useful, for instance, to have available several levels of signature, depending on the number of signers having already signed (only the last signer having access to a signature triggers a final update). Likewise it is possible to define a seemingly impossible choice (by means of an always wrong condition of type 1=0). This choice may be forced using a signature action triggered by another Workflow event. Escalations in signature processes are dealt with in this manner in standard parameterizations.

This column is used to indicate a number of miscellaneous table containing response reasons.
If this column is entered, a response reason will be asked upon event signature.

This column contains the name of a field stemming from one of the tables of the triggering context. This field will be updated with the value calculated from the next expression, during the signature process. For instance, it is possible to update a field such as ENAFLG (Active flag) of the current object during a signature process.

This column is used to define the expression of a value calculated at the moment of signature. The value corresponding to the chosen answer line will be used, in case of signature :

• either to update the field defined in the previous column with this value.
• or when triggering any actions defined in the next tab. In that case, the corresponding value is recovered from the [L]RESULT alphanumeric variable.

If this field is set to Yes, the value calculated in the corresponding column is proposed, after the signature choice, in order to enable modifications. For instance, this enables a detailed modification to be entered. The value resulting from the entry will be used to complete the update, if any, and then transmitted to the [L]RESULT variable for processing by an additional action.

This field contains an action code whose execution can be triggered if the conditions are met. It should be noted that this action must have the box Workflow checked, and, as a consequence, it cannot interact with the user interface (no associated window).

This field, whose values are defined by the 2923 local menu, defines the Workflow triggering conditions. The following values can be used :

• Workflow start : the action is triggered at the beginning of the message text construction. In case of a Line type Workflow, the action is only carried out once by header, before the header text is constructed. Those variables returned by the action can be used in the mail text (but rather to specify the recipients or sending conditions, which are already evaluated at this stage).
• Workflow end : the action is triggered after the message has been sent. In case of a Iine type Workflow, this action is only carried out once by groups of lines.
• Before Line : the action is triggered before the first line is read, in case of a header and line type Workflow. For instance, this is used to initialize totals variables to obtain the total of lines, the total being performed in a Line action.
• Line : the action is triggered just before each line of the message is constructed, in the case of a line-type Workflow. Consequently those variables returned by the action can be used in the line text.
• Signature : the action is triggered after entering the signature (so the [L]RESULT variable coming from this entry is known), but before the update (this value can be modified during the action). In the case of a signature, all the updates are carried out during a single transaction. In this way, if a Rollback is performed within one of the actions triggered by the event, the situation as it was at the beginning is restored for all performed updates.

Generally speaking, from a transaction viewpoint, it should be noted that the action belongs to the message Workflow transaction (if a Rollback is carried out during message construction, the updates completed within the action are impacted). An independent transaction is performed for the approval request (but since this transaction is carried out afterwards, the values returned by the action can be used).

In the specific case of the object Workflow, everything is performed within a single transaction. In other words, if the creation or modification of a record fails, a Rollback is performed on all the updates triggered by the actions.

It is the same for the approval request : the transaction that follows the entry of the approval request includes the action triggering.

A logical expression is entered here and it is assessed within the action triggering context. If the evaluation result is true (i.e. not null), the action is triggered. If the result is wrong, the action is not triggered. If no expression is entered, the action is always triggered.

Here is entered an evaluated expression transmitted as argument to the action, or the code of a variable that will contain a return value (if the argument is of the Pointer type). All the variables of the Workflow context can be used here.