Usage > Workflow monitor 

The Workflow monitor is used to present those events pending signature by a given user. This presentation, that can be set up by transaction, can be performed on one or more tabs. From each event, it is possible to view information relating to the triggering context, the messages sent or the signature history. The event can also be signed or approved, depending on the cases.

Prerequisite

SEEREFERTTO Refer to documentation Implementation

Screen management

The entry in the workbench is performed on a varying number of tabs, depending on the selected transaction. On each tab, there is information that can be different and set up on a case by case basis. In a similar way, each of these tabs can display all or part of the events to be processed, the allocation being performed based on rules that can be set up. Finally, the events can be highlighted (by color, font size) or sorted out according to different criteria on a case by case basis.

Header

Presentation

The header describes global filtering criteria on events to be processed, knowing that finer filters can exist on each tab of the function.

Close

 

Fields

The following fields are present on this tab :

  • 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.

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.

Close

 

Tab Workbench

Presentation

The Workflow notifications for which a signature or approval rule has been set up can be found in each tab of this type (there may be up to 8 of them).

The default information sorting order and the highlighting (using a particular style) of those lines that need to be stressed can be set up by tab.

Close

 

Fields

The following fields are present on this tab :

Block number 1

  • 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.

Table

  • 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.

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).

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.

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.

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.

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.

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.

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.

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.

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.

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.

  • 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.

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.

  • 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.

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)

 

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.

 

 

 

 

 

 

 

 

Close

 

Functions accessed by right click on the grid

Triggering operation

This function is used to zoom back to the function and original context of the Workflow. In the case of an object Workflow, the zoom back is performed to the corresponding record.

Original triggering operation

This function can be accessed when the event at the origin of the notification is of Signature type; in this case, the zoom back is performed to the original event (if need be, in a recursive way) in order to find out the function and record that triggered the start of the process.

Return

This function is used to return to the function and context described by the return icon of the Workflow setup. If nothing particular has been defined, it is the operation of origin that is proposed.

Group mails

Fields

The following fields are present in this window :

Table Recipients

  • Work flow address (field DEST)

It defines the messaging addresses to which the notification has been sent as main recipients.

Table Copy

  • Work flow address (field COP)

It defines the messaging addresses to which the notification has been sent as recipients in copy.

Object

  • field TEXOBJ

It defines the Object field of the message as it has been sent.

Message

  • field TEXTE

It defines the text of the message as it has been sent.

Block number 5

  • Request read receipt (field REQREC)

This box is checked if a read acknowledgement has been requested when the message was sent.

Close

This function is used to display in a selection window the list of messages sent to all users to whom the notification is destined.

There is a line for each group of recipients defined by a line in the setup grid of the Workflow recipients.

When double-clicking on one of these lines, a window opens to display the detail of the sent message and the list of recipients.

Mail history

Fields

The following fields are present in this window :

Table Recipients

  • Work flow address (field DEST)

It defines the messaging addresses to which the notification has been sent as main recipients.

Table Copy

  • Work flow address (field COP)

It defines the messaging addresses to which the notification has been sent as recipients in copy.

Object

  • field TEXOBJ

It defines the Object field of the message as it has been sent.

Message

  • field TEXTE

It defines the text of the message as it has been sent.

Block number 5

  • Request read receipt (field REQREC)

This box is checked if a read acknowledgement has been requested when the message was sent.

Close

This function allows the display in a selection window of the list of messages sent to the successive users having signed the notification of origin and the following notifications (when the signature process occurs at several levels).

The lines appear in the reverse chronological order (the most recent signatures first).

When double-clicking on one of these lines, a window opens to display the detail of the sent message and the list of recipients.

Signature

This function is used to trigger the line signature process. It is only available if the user has been granted signature authorization and if the line has not been signed already.

A window opens then to propose a selection of possible answers, depending on the setup. An additional reason can also be entered depending on the setup, it can even be free text (for instance, to motivate a refusal).

Approval

This function is used to approve the line. This function is only available if the line has not been signed. No other entry is requested, since the line switches to the Approved status as early as this operation has been performed.

Cancel

This function is used to cancel a granted signature (by returning to the former request status).

It is only available if the following conditions are all met:

  • the line has been signed
  • user and signer are the same person
  • the cancellation right has been granted to the user (it is one of the options of the function).
  • There is in the signature process an answer associated to the CAN operation code. This reason code will trigger the signature cancellation action by switching the line back to its former status before the signature. Another signature type workflow, based on the original rule and the CAN reason code, can then be triggered, if need be.

This operation is different from a request rejection or refusal operation that will be dealt with in an entirely conventional way by standard setup.

 

Fermer

 

Error messages

The only error messages are the generic ones.

Tables used

SEEREFERTTO Refer to documentation Implementation