Standard Ad-hoc Workflow

enaio® 11.10

This model includes commonly encountered work items that make up workflows in organizations: confirmation of notice, approval, poll, follow-up inquiry, collaboration, revision.

The standard ad-hoc model aims to immediately create significant added value in terms of productivity and process reliability in installations. At the same time, the standard model can be used in an introductory phase for standardized workflow processes to evaluate the possibilities and thus electronically map the informal processes that have existed up to now without anchoring the users' workflows in fixed structures. In this way, recurring sub-processes can then be stored step by step, initially in circulation slips, and then transferred to defined models.

The standard ad-hoc model is geared to very common use cases. Consequently it does not use all the technical possibilities of the workflow. Changes to the model by the operator are not foreseen to ensure the model's broad usability and ease of maintenance. However, at the same time, an analog model can be developed by the operator or in the project to implement specific requirements more precisely.

Configuration

The standard ad-hoc model is configured in three steps:

Import and enable the osdefaultmodels.xml model.
Assign people via the organizational model.
Optionally, you can set up object types for logging and configure a storage location for the log.

Importing the Workflow Model

You can import the workflow model via enaio® editor-for-workflow.

Start enaio® editor-for-workflow.
Select the Import organization function from the toolbar or the File menu.
Open the file osdefaultmodels.xml via the file selection dialog.
Mark the 'System projects' area in the Source area and 'Organization' in the Destination area.

You can also use the mouse to drag the 'System projects' entry to the 'Organization' entry.

Then click the Add button. The project will be imported and the dialog will close.

Open the model explorer. The new system project will be displayed.

The imported models are read-only and cannot be edited.
Select the model and activate it using the corresponding function from the context menu or the toolbar.

During the automatic check, you will receive the message that no record owner has been entered. This function is automatically imported via events by the user who starts a process. At the end of the process, all documents from the workflow file that do not yet have a location are transferred to the personal tray.

In so doing, the model is integrated and activated. You integrate roles and persons in the following step.

Configuring the Organizational Structure

When installing enaio®, the 'Ad-hoc' role is automatically created and inserted within the organizational structure on the top level. All persons who you add as sub-objects of the 'Ad-hoc' role in the organizational structure can start ad-hoc processes and taskflows in enaio® client if they have the 'Client: Use workflow' system role.

All persons and roles from the organizational structure in enaio® client can be entered as participants for the ad-hoc processes when configuring the circulation slip of an ad-hoc process.

Edit the organizational structure via enaio® editor-for-workflow:

Start enaio® editor-for-workflow.
Open the organization explorer via the workspace.
Assign objects of the class 'Person' to the 'Ad-hoc' role.

Save the changes.

When this step is complete, ad-hoc operations can be started and executed in enaio® client.

If you import users in the organization explorer, you can assign them the 'Ad-hoc' role straight away.

Configuring a Logging

Part of the 'Ad-hoc' model is the 'Log' activity, which, controlled by events, compiles all data from completed activities in a log. The activity is run automatically if it has been included in a running list. Afterward, the log is located as a document in the workflow file. The log can be assigned to a document type, indexed, and saved to a location in the following activity. If this is not done, the log is automatically placed in the personal tray of the user who started the activity after it has been completed.

A configuration can be used to define the format for the log and to configure a location where the log is automatically saved. This configuration is optional; without configuration, the log is placed in the workflow file as a PDF.

The following object types are defined in the object definition file for ad-hoc workflow logging:

'WF log' folder type

'General' register type

'Protocol_PDF' document type

'Protocol_XML' document type

The configuration file is harmonized with this object definition. A folder is created for each year, a register for each month, and there a document with the log data.

The document is tagged with the process name, the process ID and other data.

Transferring the Object Definition

Use enaio® editor to open the object definition file objdef_osdefaultmodels.xml.

You copy the cabinet, register, and at least one document type into the system object definition. You only need the document type that corresponds to the desired log format.

Then you save the object definition and adjust the tables.

You will need the internal names of the object types for further configuration.

Users with the 'Ad-hoc' role need the access rights in the security system to be able to create the folders, registers, and documents configured here for logging.

Log Configuration File

Use the log configuration file osDefaultModels_Config.xml to specify the file format in which the logs are created and where they are saved.

The file must be copied to the \etc directory of the data directory. If you do not change the file, log files are created in PDF format.

The prerequisites for protocols in PDF format are OpenJDK on each participating enaio® server and the setting of the environment variable JAVA_HOME to the Java installation path ...\java\jdk\.

The protocol configuration file is configured using the following information.

Protocol type

Enter 'XML', 'PDF' or 'NONE' as the protocol type. Enter 'NONE' if you only want a log in the file and do not want an automatic transfer to a location. The user can take the log from the file as required. At the end of the process, logs are moved from the file to the user's filing tray. The document type for the log file is then taken from the following configuration.

Folder type

You specify the internal name of the folder type.

<Folder>
<object InternalName="WF_Protocol"><value>WF_Protocol</value></object>

Folder field names

You need to enter the internal field names for the folder fields to which the model name and the year are assigned.

<Fields>
<Family InternalName="WF_Family"><value>WF_Family</value></Family>
<Year InternalName="WF_Year"><value>WF_Year</value></Year>
</Fields>

You specify the internal name of the register type.

<Register>
<object InternalName="WF_General"><value>WF_General</value></object>

Enter the internal field names for the register field to which the month is assigned.

<Fields>
<Month InternalName="WF_Month"><value>WF_Month</value></Month>

Document type

You specify the internal name of the document type that you have set up in the object definition for the desired file format.

<Document>
<object InternalName="ProtokollDoc"><value>Protocol_PDF</value></object>

For the PDF format: Protocol_PDF. For the XML format: Protocol_XML.

Document type field names

You specify the internal field names for the document type fields to which data is assigned.

<Fields>
    <ProcessName InternalName="WF_ProcessName"><value>WF_ProcessName</value></ProcessName>
    <ProcessId InternalName="WF_ProcessId"><value>WF_ProcessId</value></ProcessId>
    <Comment InternalName="WF_Comment"><value>WF_Comment</value></Comment>
    <Status InternalName="WF_ProcessStatus"><value>WF_ProcessStatus</value></Status>
    <ProcessUser InternalName="WF_ProcessUser"><value>WF_ProcessUser</value></ProcessUser>
    <ProcessCreator InternalName="WF_ProcessCreator"><value>WF_ProcessCreator</value></ProcessCreator>
    <Workflowprotokoll InternalName="Workflowprotokoll"><value>Workflowprotokoll</value></Workflowprotokoll>
    <osDate InternalName="WF_PROT_ROW1"><value>WF_PROT_ROW1</value></osDate>
    <osTime InternalName="WF_PROT_ROW2"><value>WF_PROT_ROW2</value></osTime>
    <osActivity InternalName="WF_PROT_ROW3"><value>WF_PROT_ROW3</value></osActivity>
    <osUser InternalName="WF_PROT_ROW4"><value>WF_PROT_ROW4</value></osUser>
    <osAction InternalName="WF_PROT_ROW5"><value>WF_PROT_ROW5</value></osAction>
</Fields>
                                                            

You can also change this configuration to other archive object types. A structure consisting of folder type, register type, and document type is necessary. The assignment is always made via internal names.

If you specify the XML format for logging and the assigned document type 'Protocol_XML', you can assign the stylesheet osdefaultmodels.xsl, which must be copied to the \etc\templates directory of the data directory, to the document type for viewing in enaio® client via an entry in the as.cfg file from the \etc directory of the data directory.

Further Configuration Parameters

Administrative protocol

An additional administrative protocol can be configured. It is created as a weekly TXT file.

<Debug>
  <object id="C_DEBUG_ON"><value>yes</value></object>
  <object id="C_DEBUGLEVEL"><value>3</value></object>
  <object id="C_DEBUG_PREFIX"><value>Debug_osDefaultModels</value></object>
</Debug>
                                                            

C_DEBUGLEVEL: Flow=3, Info=2, Error=1

Protocol creator: TechnicalUser

The logs are created as standard with the rights of the process creator. A different user can be specified.

Protocol as a document without pages

During initialization, the log can be created as a document without pages. The log is updated with every activity.

If the protocol is created as a document without pages, the participants can be entered in the 'Access for' field. The field is linked to the rights group add-on. Access to the protocol can be configured via access clauses.

The number of entries in the 'Access for' field can be restricted. The standard is 10 entries. All does not limit the number. A limit can be useful if participants are assigned via roles with many users and the field length cannot accommodate all entries.

Links between logs and file objects

File objects can be automatically linked to the logs.

Logs at the location of the first file object

Logs can be created at the location of the first file object. A document type with corresponding fields must be available at the location.

The document type is not specified via the internal name, but via the designation.

Server language and logs

The server language determines the application language in which the activity names are written in the workflow log table and the names in the log.

Application languages: GERMAN / ENGLISH / FRENCH

Taskflow: Information from the initiator

This automatic information of the initiator about the completion of the task flow can be deactivated.

Standard Ad-hoc Workflow – Process

The standard ad-hoc workflow provides the model for processes that users can quickly and easily learn, but at the same time are complex enough to organize a large part of daily recurring work processes.

The standard ad-hoc workflow consists of an area with seven coordinated activities, which – in contrast to the structured workflow – are not connected by predefined transition paths, but from which a flexible flow is created by the users only in the process. Three different processes are executed with these activities: coordination processes, release processes, and information processes. These processes can be combined in any way, and can also be executed more than once. A workflow is finished as soon as no more activities are listed on the circulation slip.

The file of the standard ad-hoc workflow can be edited by each participant in every step. The technical process can be clearly viewed in each step on the Log tab. Each step provides an area in which users can enter information for an annotation history. This can also be viewed by all users on the appropriate tab in each step.

The standard ad-hoc workflow can be executed in enaio® client as well as in the enaio® webclient. All steps are available in English, German, and French.

In the following, the individual activities are described with their relations to the preceding and following activities.

Initialization

An ad-hoc process is started from enaio® client via the 'Startable workflows' inbox. The person who starts a process becomes its initiator. If a process is completed and there are still documents and logs in the workflow file that do not have a location in enaio®, these are placed in the initiator's personal folder.

The first process step of the started process is always 'Initialization'.

The workflow screen of the process step has three editable areas on the General tab:

Subject

Subject is a mandatory field and must be filled in. The subject identifies all the steps of the process in the inbox and can be used for indexing log files. For this reason, it makes sense to enter a meaningful description for the process in the Subject field.

The entry in the Subject field can only be changed in a further process step 'Initialization'.
Comment

The comments field is displayed in all steps, and can also only be changed in another process step 'Initialization'. An entry in this field will be shown in all following steps and also transferred to the annotation history.
Poll

The Poll field is used to specify options for a poll via a table in a follow-up 'Poll' step. Poll options can be changed in a follow-up 'Revision' or 'Initialization' step. If voting has already taken place, any changes will always reset existing voting results.

The poll options entered here will be shown in a list in the 'Poll' step from which participants select the required option. The option 'No opinion' for the poll is added automatically.

A poll is a multi-instance activity and can be executed by several participants. Polling is automatically closed if either all participants have cast their vote or if the votes cast for a specific option exceed an amount in percent specified.

The poll result is shown in the follow-up 'Confirmation of notice' step and on the Log tab.
Create log

The creator can determine whether a log is created. The log configuration determines which type of log is created.
Result e-mail

The creator can activate the sending of a result e-mail.

The Circulation slip remark field shows the comment for this activity entered in the circulation slip.

Circulation slip comments are optional. This field remains empty in the first initialization step.

When forwarding, the user receives a note if no objects have been placed in the file.

All follow-up steps, except for another initialization, show which participant initialized the process on which date on the Annotation history tab in the fields Initiator and Start date.

The annotation history on the corresponding tab remains empty in the first step.

Revision

You will find in the 'Revision' step the corresponding entries from initialization in the fields Subject and Comment and in the field Circulation slip remark, the entry that was specified in the circulation slip as a comment for this activity. These three fields are read-only.

Entries in the Note field will be entered in the annotation history and are shown in all subsequent follow-up steps.

Poll options can be specified or revised in a table, just as during initialization, on the Edit poll options tab. If polling already occurred during a previous step, this poll data will be deleted and can be accessed, provided that it was saved during a preceding logging step.

Collaboration/Follow-up Inquiry

In the 'Collaboration / Query' step, you will also find the corresponding entries from the initialization in the read-only fields Subject and Comment and the entry that was specified as a comment for this activity in the Circulation slip comment field.

Entries in the Answer field are transferred to the annotation history and are visible there in all follow-up steps.

Poll

The form in the 'Poll' step shows as a selection list the poll options specified during initialization or revision via a table.

In addition to the poll options entered, the participant always has the option to select the 'No opinion' option. The Poll field is a mandatory field and must be filled in.

Polls are multi-instance activities and can be executed by several participants.

Polling is automatically closed if either all participants have cast their vote or if the votes cast for a specific option exceed an amount in percent specified.

The poll result is displayed as a table in the 'Confirmation of notice' step on the Poll result tab. You can view how the individual participants voted on the 'Log' tab. The contents of this logging table can be copied to the clipboard via the context menu or pressing Crtl+E.

The number of 'No opinion' votes will not be shown in the table.

Approval Activity

The fields Subject and Comment contain the corresponding entries from initialization and in the field Circulation slip remark, the entry that was specified in the circulation slip as a comment for this activity.

In the 'Approval activity' step, an option from the Decision area can be marked: Open, No approval, or Approval granted.

The selected option is logged and can be viewed in all follow-up steps on the Log tab.

If this is followed by a follow-up 'Approval activity' step, the option you previously selected will be preset.

Entries in the Note field will be entered in the annotation history and are shown in all subsequent follow-up steps.

Confirmation of Notice

You will find in the 'Confirmation of notice' step, as well, the corresponding entries from initialization in the read-only fields Subject and Comment and in the field Circulation slip remark, the entry that was specified in the circulation slip as a comment for this activity.

Entries in the Note field will be entered in the annotation history and are shown in all subsequent follow-up steps.

If there was a previous poll, you will find the poll result as a table on the Poll result tab. You can view how the individual participants voted on the 'Log' tab.

Information on approvals can be found on the Log tab.

Log

The 'Log' step has no participants. It is not started by any participant; it is performed automatically. If the step is included in the circulation slip, a log file containing the data of all items performed so far is generated and stored in the workflow file. This log file can be viewed during any following step.

The 'Log' step can be at the end of a process. If no further step follows, a log file that has not already been assigned a location and document type via a configuration is placed in the initiator's tray like all documents without a location from the workflow file.

In addition to this logging, a technical process log is automatically created on the Log tab. This logging contains approval information, for example; however, it does not contain notes from the individual steps. These can be viewed via the annotation history.

The contents of the Log tab can be copied to the clipboard via the context menu or pressing Crtl+E.

Escalation for Standard Ad-hoc Activities

An escalation set up in the model can be assigned to an activity in a circulation slip. The following escalations are possible for all activities in the standard ad-hoc workflow:

Remainder e-mail

If a process step has arrived in a user's inbox and is not forwarded within a specified time period, the user will receive an e-mail to this effect. The time period will be specified via the Due on and At fields.

This is subject to the e-mail address being specified in the workflow user administration.
Automatic forwarding

The process step is automatically forwarded to the follow-up activity when the end of a time period is reached. Both personalized and non-personalized work items are forwarded. The preset time period of two days can be changed in the Due on and At fields.
Assigning a work item to a substitute

If a process step arrives in a user's inbox and is not forwarded within a specified time period, the process step will automatically be assigned to the substitute. The time period is specified in the Due on and At fields.

For this to happen, a substitute must be set up in the workflow user administration.