Refer to documentation Implementation
The setup screen of the Workflow rules is comprised of 5 tabs, with the first three concerning the basic setup (in simple notification cases, the main fields of these three tabs need to be documented) and the other two enabling an advanced setup :
Presentation
A rule is identified by means of a code but, for organization purposes, it may be associated with a category defined in a miscellaneous table. This is therefore the information that can be found in the screen header.
Close
Fields
The following fields are present on this tab :
Block number 1
| This field identifies the Workflow rule. |
| Use this field to assign a description to each record. |
Block number 2
| 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. |
Close
Presentation
This tab defines the triggering context, specified by a type of event and an associated code along with, in some cases, additional operation codes. There also is a conditions grid: these conditions must be verified for the rule to be triggered. Since some events act upon data organized according to a header and line structure, it is necessary to specify about which level each of these conditions are.
It is also possible to associate a rule with a data template which describes a group of additional tables which will be read when the rule is tested. For a rule whose type is Manual, this data template is mandatory, since the only existing context is linked with this template. For rules linked with objects or miscellaneous events, this model is optional, and is simply used to fill the on line tables.
Depending on the type of rule and the template associated to it, it is possible to specify if the workflow should be about the header information or the line information, and, if need be, the manner in which to group the lines.
Finally, an allocation rule can be set to specify how the recipients of the message will be defined. Such a rule can send back one or several recipients. The concerned recipients may receive the notification coming from the rule or may be transmitted to the next rule, in case of a signature sequence.
A technical appendix will contain details on the information available within the execution context.
Close
Fields
The following fields are present on this tab :
Triggering event
| The Workflow event type can take the following values :
|
| This field specifies the triggering context, based on the previously defined type :
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 :
|
| 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). |
Block number 4
| 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:
|
Block number 5
| 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 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 :
|
Grid Conditions
| 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 |
Management
| 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:
|
| 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. |
|   |
Close
Presentation
This tab is used to enter the list of the recipients of the messages or notifications. A recipient can be defined as a user (their e-mail address is mentioned in the user record) or a BP (concerned contacts are then identified by their functions).
Each line in the grid defines one or several recipients (according to the selected delegates option), and these recipients can receive :
The group of recipients defined by a grid line is considered to be interdependent from a signature standpoint: only one member of the group needs to sign for the line to be considered signed (since the name of the signer is propagated to the pending signatures for the group).
On the other hand, if there are several lines, the signature of one of the recipients is not propagated to the other lines. Within a signature context, it will then be possible to test the number of groups (lines) who have already signed, in order to trigger an update while taking account of the other signers, if needed.
Fields
The following fields are present on this tab :
Grid Recipient
| 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 :
|
| 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 :
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 value of this field defines who is the recipient of the notification or message :
|
Presentation
This tab is used to define the content of the message sent to the concerned recipients. A message is comprised of :
In addition to these elements, a certain number of additional fields define the sending conditions along with the information (enclosings) which can be enclosed in the message.
The general setup TYPMES must be equal to Server to allow enclosings to be sent. Otherwise, only the first enclosing is sent (a warning message appears when forcing a message transmission via Client). Moreover enclosings must be accessible from the application server (following a network path if the enclosings are not stored in the database).
The sending of e-mails is dependent on the use of an e-mail system accepting a MAPI interface when sending from the client workstation or SMTP POP3 when the message is sent from the server (this is the case for the majority of e-mail systems available on the market).
The recipients of the Workflow notifications can be directly set up in the rule, either via a user code or via a BP code and a contact type at the BP's. It is also possible to create multi-criteria tables called allocation rules that enable a BP user to specify the recipients on the basis of predefined criteria values.
Close
Fields
The following fields are present on this tab :
Message
|   |
| 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. |
Text
| 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 |. |
Management
| 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. |
Management
| 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). |
Block number 6
|   |
|   |
|   |
|   |
Block number 7
| 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 :
|
| 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. |
Attachments
| 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 :
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). |
Close
Presentation
This tab is used to define Suivi Approval Request type notifications in the planning workbenches of the recipient users and the associated signature conditions, if any. These signature conditions only apply if, in the recipients grid of the corresponding tab, the users are in a request approval mode With signature. With signature.
The message to be displayed in the planning workbench along with the signature deadline when a signature is expected are defined in the form of evaluated expressions.
In addition a grid specifies the answers that the user may give upon signature, and there is also the possibility to directly update a field of the current record in the case of an Object type Workflow. Objet.
It should be noted that the elements evaluated in the answers grid are evaluated upon signature whereas those elements relating to the notification or the associated message are evaluated upon release of the source Workflow. In other words the context is no longer exactly the same. In this way, within an object-type Workflow context, the following elements are available on-line:
A grid named Context is used to transmit values of the triggering context to the signature context. Contexte. Expressions described in this grid are evaluated and transmitted upon signature in the form of a grid of local variables named [L]CTX. These variables can then be used in the setup of the planning workbenches, in the conditions and values linked to the signature, and also in the values and variables linked to the Actions of the next tab, in the case of actions released upon signature.
Close
Fields
The following fields are present on this tab :
Text
| 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. |
Signature
| 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. |
Grid Context
| This table contains expressions evaluated when the Workflow is triggered. These variables :
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 :
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. |
Grid Answer
| 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. |
| 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 :
|
| 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. |
Close
Presentation
In a first grid, this tab describes a list of actions which can be released when triggering the event or during the signature phase. Thus either predefined standard actions (a list of these actions is drawn up in the corresponding technical appendix) or specific actions can be called. It should be noted that the concerned action is only called if the execution condition is met.
The grid located below is automatically loaded with the list of the action parameters, in order to enter a list of expressions evaluated in the context and transmitted (either as values, or as pointers; in the latter case, the return values can be used later on).
Close
Fields
The following fields are present on this tab :
Grid 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 :
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. |
Grid Parameters
|   |
|   |
|   |
| 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. |
Close
The following fields are included on the window opened through this button : Block number 1
Block number 2
Close This button is used to copy a Workflow event to another folder, by simply giving its code. In the opening box, a check box allows the transfer to all the other folders defined in the current folders grid. |
This option is used to directly release a Workflow when it is a manual one. The dialog box used to enter any associated parameters is then completed.
This menu item allows access to the documentation management on the first paragraph of the documentation (if there is one) associated with the current record.
This menu item allows access to link management. It is used to define the links between the current record and other records (for example, the links between functions and parameters). These links are specific to the documentation and are used to load the generation of documentation structures.
This menu item launches a documentation generation. You can also launch it from the Generation button at the bottom of the screen.
You can launch three types of generation one by one or simultaneously
The range suggested by default takes into account the current record, but you can modify it at launch time.
In addition to the generic error messages, the following messages can appear during the entry :
An allocation rule which is not based on the previously defined data template has been defined in the first tab.
In a Workflow event associated with an import / export, it is recommended to specify in the operation zone, by means of a combination of codes (I or E, and S or E), whether the Workflow is triggered during an import or an export, at the beginning or at the end.
In a Workflow event associated with an object, the entered X operation does not exist.
A syntax which does not correspond to a valid link expression has been entered.
It is impossible to run through a structure with links (1,N) in the case of a manual Workflow. It is required to always start from the finest level of detail and create links (1, 1) towards the header. This does not prevent lines to be then grouped on the value of the header key, by acting upon the grouping criterion.
It is merely a warning, displayed when a Workflow rule is created at the end of a batch task, by specifying a task for which the user notification is disabled.