Workflow Monitor

• Exceptional delegate (field DELEXP)

When this box is checked, the user sees the notifications sent to the users for whom said user has been granted an exceptional delegation.

This box can only be checked if the user has at least one such delegation.

• Recipient (field USER)

It defines the code of the user who is recipient of the Workflow events that are pending signature and need to be viewed.

This code can only be entered in two cases:

• If the All users option is granted to the current user for the function.
• If the Exceptional Delegate box is checked (in this case, it is possible to choose the user to whom an exceptional delegation has been granted and whose notifications need to be viewed).

If this field cannot be entered, it is by default equal to the user current value.

If this field can be entered, but no value has been assigned, the following notifications can be viewed:

• those of the users for which there is an exceptional delegation, provided the Exceptional Delegate box has been checked.
• otherwise those sent to all the users.

• Start date (field DATDEB)

If this date is entered, only the data where the last modification or creation date is later than or equal to it are viewed in the inquiry.

It should be noted that the proposed date is by default today's date, decreased by a number of days equal to the value of the WRKDAY parameter.

• End date (field DATFIN)

If this date is entered, only the data where the last modification or creation date is earlier than or equal to it are viewed in the inquiry.

By default this date is equal to today's date.

• field PAGFIR

Navigation buttons that allow all the lines of the workbench to be run through.

• field PAGPRV

• field PAGNXT

• field PAGLST

• field W

• field PAGCUR

• field SAICRI

Button that makes it possible to open an entry screen of a line selection criterion in the form of a logical expression.

• Sequence no. (field CHRONO)

Chronological number assigned when a Workflow is triggered. In the case of a Manual workflow, a number is assigned for each triggering record. In all the other cases, a single chronological number is assigned per triggering record.

Thus, when a notification is sent to several users from the same event, the chronological number is the same.

• Recipient (field DEST)

It defines the notification recipient. If an approval or a signature is expected, it usually is up to them to provide it.

This recipient is not necessarily the recipient who was defined in the original rule. Indeed, if the rule foresees a delegation to the first available recipient, and the original recipient has specified a delegate with authority for the concerned dates, the delegate will be the one to receive the notification (or their delegate if they have themselves designated a delegate...).

• Recipient e-mail (field EMAIL)

When a message is sent by the rule to a recipient, the latter's e-mail address appears in this field.

• Workflow no. (field NUMGRP)

This sequence number is assigned for each line dealt with (so there are several of them in the case of header/line Workflows with groupings).

• Company (field CPY)

When a data model is attached to the rule and this model defines a current company depending on the context (either directly or via a site), the corresponding company is stored in the event.

This company can be used (but it is not compulsory) to define the allocation rule that will specify the recipients of the notification.

• Delegate (field DELEGUE)

This field is set to No if the user is the first notification recipient. It is set to Yes if the user receives the notification as a non-replacing delegate (All or Cascade options), and if, at the same time, said user has the signature authority (if they do not have the signature authority, the notification does not appear in the workbench).

It should be noted that if this field is set to Yes, there is at least another line bearing the same sequence number with the No value in the table that stores the workbench data (there may be other lines with the same sequence number and the flag being set to Yes if there are several delegates with signature authority). The first signature on one of the concerned lines automatically updates all those lines that bear the same sequence number by considering them signed.

• Send mail (field ENVOI)

This field is equal to Yes if a message has been sent during the execution of the rule.

• Sender (field EMETTEUR)

It defines the notification issuer, in other words, the user whose action has triggered the Workflow. In a Signature Workflow, the issuer is the one who has signed the previous notification. For any other Workflow, the issuer is the user whose action triggers the sending of the notification.

• Email transmission (field MAIENV)

When a list of the workbench has been signed by an http link being triggered from a message, this field stores the e-mail address of the user who has signed in such a manner.

• Issue date (field DATENV)

It corresponds to the system date (as it is known to the processing server) at the moment when the Workflow event is being executed.

• Issue time (field TIMENV)

It corresponds to the system time (as it is known to the processing server) at the moment when the Workflow event is being executed.

• Type of workflow (field NATURE)

It corresponds to the value of the Workflow nature defined for the triggering event. It can represent a convenient criterion to sort out the lines, filter them or dispatch them to various tabs of the workbench.

• Tracked text (field TEXSUI)

It contains the evaluated text from the Approval request text section defined in the Approval request tab of the rule. Usually a comment is parameterized to explain the Workflow triggering circumstances.

• Event type (field TYPEVT)

It defines the event type of the Workflow rule at the origin of the notification line in the workbench.

• Event code (field CODEVT)

It corresponds to the event code at the origin of the Workflow, in other words, to the code of:

• the object, in the case of an object Workflow.
• the report, in the case of a printing Workflow.
• the model, in the case of an import or an export.
• the function, in the case of a function opening.
• the Workflow rule having triggered the signature request, in the case of a signature.
• the code identifying the miscellaneous Workflow, in such a case.

• Workflow code (field CODWRK)

It identifies the Workflow rule whose execution has sent the notification.

• Action on (field OPERATION)

It contains the operation code in the triggering context:

• for an object event, it may be C (Creation), M (Modification... or the button code.
• for a signature event, the code of the rule at the origin of the signature.
• for an import/export, the I/E and S/E combinations (Import/export and Start/Finish), for instance ID.
• to start a function, the field is empty.
• for a printing, it is equal to C.
• for the end of a batch task, it is equal to "0" if the task has been successfully completed, otherwise, the report number followed by the beginning of the error message is used.

• Signature leadtime (field DATMAXSIG)

This field contains the date on which the Workflow shall have been signed. It is equal to the triggering date if no signature process has been implemented, or if no deadline has been defined.

In fact, when the Workflow event expects a signature :

• a date limit can be managed in the Workflow (using the section that gives a corresponding calculated expression in the Workflow parameterization).
• there is then the possibility to trigger reminders based on this date limit. These reminders are created by the Workflow batch rules named WRKREM1, WRKREM2, and WRKREM2E.

When a reminder of this type is made :

• the Number of reminders field is increased, which is then used to identify how many times the signature has been re-launched.
• the Last reminder date is updated, which is used to identify the date on which the last signature has taken place.

If these batch rules are not used and if no other rule has been defined to change these fields, the number of reminders remains equal to 0 and the reminder date remains empty, because no other standard Workflow process can modify this value.

• Signature flag (field FLGSIG)

This field defines the signature level corresponding to the line notification. It can take the following values defined in the local menu 2922:

• To be read : a read notification is requested, but the notification has not yet been read.
• To be signed: a signature is requested, but the notification has not been signed yet.
• Read : a read notification has been requested, it has been entered.
• Signed: a signature has been requested and it has been granted.
• Cancelled: a signature has been granted, then it was the subject of a signature cancellation.

• Answer (field ACTSIG)

This field is empty as long as the event has not been signed. If it has been signed, the entered answer code can be found, as is it defined in the miscellaneous table number 54.

• Signer (field USRSIG)

When a line in the notification grid has been signed, the code of the user who has signed appears here. It is not necessarily the original recipient, since another user may have been granted the authority to sign.

• Email signature (field MAISIG)

When a message containing an approval request by activation of an http link has been sent, this field makes it possible to find out the e-mail address of the recipient.

• Signature date (field DATSIG)

If the Workflow notification involves an approval request (simple approval or signature), this field makes it possible to find out the date on which the approval request has been performed (it stays empty has long as the approval request has not been performed).

• Signature time (field TIMSIG)

If the Workflow notification implies an approval request (simple approval or signature), this field makes it possible to find out the time when the approval request has been performed (it stays empty has long as the approval request has not been performed).

• Response reason (field REASON)

It contains the title associated with the reason code entered upon rule signature, when this entry is possible upon signature. This supposes that a list of possible reasons be defined via a miscellaneous table number on the corresponding signature line.

• Reason code (field REACOD)

It contains the reason code entered upon rule signature, when this entry is possible upon signature. This supposes that a list of possible reasons be defined via a miscellaneous table number on the corresponding signature line.

• Reason no. (field REANUM)

When a reason code entry has been planned upon rule signature, this field contains the miscellaneous table number that defines the possible reasons on the corresponding signature line.

• Release key (field CLEOBJ)

In the case of an object Workflow, the object key can be found in this field (it is the Original triggering key field). In the case of a signature Workflow, the sequence number at the origin of the signature can be found in this field. In all other cases, this field is not assigned.

• Triggering table (field IDENTREF)

This technical field contains the code of the triggering table along with the code of the corresponding key, in exactly the same manner as for the Line identifier field. On the other hand, in case of a signature-type event, this field remains empty, in other words, it is not transmitted from the original notification.

• Identifying return (field IDENTRET)

When a return icon is associated with the Workflow, this field contains the name of the function on which the return is performed. If the function is of object type, the corresponding key can then be found, separated from the table by a "/" (the key segments, for a key in several parts, are separated by a "~").

• Line identifier (field IDENTGRP)

This technical field includes, first the name of the table containing the original triggering event , then the current key linked to the group that caused the triggering. The separator between table and key is "/" while the separator between the key segments (when comprised of several fields) is "~".

The content is defined in the following fashion:

• concerning a Signature event, the content of the original notification is used.
• Concerning an Object event, the main table of the object is used if it can be determined (which means that nothing has been entered in the presence of a generic Workflow with an empty object code). The key corresponds to the current key during Workflow triggering.
• In all other cases, the table is defined only if a data model is attached to the Workflow. In that case, the main table is the one to be returned. The key corresponds to the current record during Workflow triggering.

• Origin chrono (field NUMORG)

This sequence number is entered only for notifications linked to a Signature type event. It is used to find out the sequence number of the original event, the one whose signature has triggered the current line.

• Original recipient (field USRORG)

This field is entered only on those lines associated with a Signature type event. It is used to find out the recipient of the original Workflow (the one who actually received the notification after possible application of the delegation rules: it is not necessarily the one who has signed).

• Reminder date (field DATREL)

This field contains the date upon which the last signature reminder has been performed for the notification. It is not assigned if no signature process has been implemented.

In fact, when the Workflow event expects a signature :

• a date limit can be managed in the Workflow (using the section that gives a corresponding calculated expression in the Workflow parameterization).
• there is then the possibility to trigger reminders based on this date limit. These reminders are created by the Workflow batch rules named WRKREM1, WRKREM2, and WRKREM2E.

When a reminder of this type is made :

• the Number of reminders field is increased, which is then used to identify how many times the signature has been re-launched.
• the Last reminder date is updated, which is used to identify the date on which the last signature has taken place.

If these batch rules are not used and if no other rule has been defined to change these fields, the number of reminders remains equal to 0 and the reminder date remains empty, because no other standard Workflow process can modify this value.

• No. reminder (field NBRREL)

This field contains the number of signature reminders performed for the Workflow event.

In fact, when the Workflow event expects a signature :

• a date limit can be managed in the Workflow (using the section that gives a corresponding calculated expression in the Workflow parameterization).
• there is then the possibility to trigger reminders based on this date limit. These reminders are created by the Workflow batch rules named WRKREM1, WRKREM2, and WRKREM2E.

When a reminder of this type is made :

• the Number of reminders field is increased, which is then used to identify how many times the signature has been re-launched.
• the Last reminder date is updated, which is used to identify the date on which the last signature has taken place.

If these batch rules are not used and if no other rule has been defined to change these fields, the number of reminders remains equal to 0 and the reminder date remains empty, because no other standard Workflow process can modify this value.

• Signature level (field LEVSIG)

This field corresponds to the signature level, when signature events follow each other:

• it is equal to O for the original event.
• it is equal to 1 for the event triggered by the first signature.
• For each event following another, it is incremented by 1.

The corresponding LEVSIG variable is frequently used in the Workflow rules when the allocation rule of the original event specifies all the signers (1 to 9 maximum). For the original event as for the signature events that follow each other, the USER(LEVSIG+1) recipient formula only needs to be specified to obtain the user number N in the list. This makes it possible, among others, to have recursive signature rules, that are executed as long as signers are left.

• Return icon (field CONTXT)

When a Workflow sends a message with a login icon enclosed, the login context (folder, server, service, function...) is defined in the form of an alphanumeric field.

This technical field contains this context. The various segments of this field are divided by the "/" character.

• Back to desktop (field CONTXTSYRA)

• Back to mobile (field CONTXTMOBI)

• Original trigger key (field CLEDEC)

It identifies the key at the origin of the Workflow circuit. When it is sub-divided into several parts, this key is a concatenation of the key parts separated by the tilde character (~).

The key values depend on the context:

• for an object Workflow, it corresponds to the key of the the triggering record.
• for a Manual workflow, it corresponds to the key of the main table on which the Workflow data model is founded.
• for an import/export Workflow, or when entering a function, nothing is entered in this field.
• for a printing Workflow, nothing is specified if the printing is launched from a printing function ((printing or group printing). On the other hand, if the printing is launched via File/Print or File/List from an object, the record key is entered in this field.
• for a signature Workflow, the key of the record of origin is inherited, it being stored on the approval request line at the origin of the signature.

• No. of signers (field NBRUSR)

It defines the number of users returned by the allocation rule, if any.

If there is none, but the rule is of the Signature type, the number of signers defined in the original rule is inherited.

If there is no allocation rule, the returned value is 0.

• Object (field ABROBJ)

When the first event at the origin of a signature cicuit is an object, this field identifies the object code. In the other cases, it is empty.

It is then transmitted to the various signature events that could follow the first one.

• First recipient (field USRTOP)

It defines the first recipient of the Workflow event. Indeed, an event can send a notification to several series of recipients, each one of them being defined by a line in the recipient grid. This field represents the evaluated recipient for the first line if the delegation option is No, All or Cascade. If the option is First available and the user is indeed not available and has granted delegation, the delegated user appears in this field.

• Context 1 (field VALCTX1)

This field belongs to a group of fifteen generic fields that store contextual values assessed upon Worflow release based on formulas entered in the grid named Context of the Request approval tab of the Workflow.

The values stored in this grid can be used for the following purposes:

• transmit to a Signature type event information useful for the rest of the process.
• display useful information in the Workflow monitor. In that case, when parameterizing the transaction, it can be given a more explicit name.

• Context 2 (field VALCTX2)

• Context 3 (field VALCTX3)

• Context 4 (field VALCTX4)

• Context 5 (field VALCTX5)

• Context 6 (field VALCTX6)

• Context 7 (field VALCTX7)

• Context 8 (field VALCTX8)

• Context 9 (field VALCTX9)

• Context 10 (field VALCTX10)

• Context 11 (field VALCTX11)

• Context 12 (field VALCTX12)

• Context 13 (field VALCTX13)

• Context 14 (field VALCTX14)

• Context 15 (field VALCTX15)

• Signer 1 (field USRSIG1)

It is used to define the successive signers, when a recipient allocation rule returns N signers for the Workflow rule. This information is namely used to correctly manage the signature cancellations.

Regarding Signature type events for which no allocation rule has been defined, the signers associated with the triggering rule are used. In this way, when N cascading signers have been defined in the original rule and all the signature rules that follow do not have any allocation rule, it is possible to find out the whole signature circuit at each level.

It should be noted that the users defined by the rule before the possible application of delegation rules appear here. For instance, if the first recipient of the signature rule is not available, and they are replaced, the Signer 1 field will contain the original signer, whereas the First recipient field will contain the replacement to whom the signature request has been actually sent.

• Signer 2 (field USRSIG2)

• Signer 3 (field USRSIG3)

• Signer 4 (field USRSIG4)

• Signer 5 (field USRSIG5)

• Signer 6 (field USRSIG6)

• Signer 7 (field USRSIG7)

• Signer 8 (field USRSIG8)

• Signer 9 (field USRSIG9)