Effector 6.3 developer manual

XML reference 6.3

Effector Studio 6.3 summary

Effector Studio 6.3 manual

Effector 6.2 developer manual

XML reference 6.0

Effector Studio 3.2 summary

Effector Studio 3.2 manual

Workflow designer

Workflow designer

This interface allows the generation, modification and management of workflows and subprocesses, while also facilitating their visual representation. The generated workflows can be tested locally on the “Workflow screen”.


Creating workflow, subflow

On the left-hand panel, new workflows can be created, or existing ones renamed. Upon clicking on the “Create new workflow” button, users can enter the name of the workflow to be created and an optional table name, should further information be stored for the workflow tasks.

It is important to note that the subprocesses cannot be used / tested on their own but as a part of a workflow. If the goal is to test only a subprocess, it can be done after creating a process with only a subprocess.


Metadata can be added to the created workflows. Workflow name, version number, creator and date of creation are defaults values, they cannot be deleted, but the later added metadata can be modified or deleted.


Naturally, you can add metadata to the subprocess.


You can give the name of the subprocess by clicking on "Create new subprocess" button.

Activating and deactivating workflows, subprocesses

Only the active workflows/subprocesses are available during system operation. Workflows/subprocesses are created as active by default, which is indicated by a green check mark on the given card. You can deactivate the given workflow/subprocesse by click on the check mark.


Copying and versioning of workflow, subprocess

You can give the name of copied workflow on the popup window after click on the copy icon on the given card. If the goal is to create new version from the given workflow you can do it by tick the proper check box. In this case the name of the workflow cannot be changed. The new version will be deactivated by default. Only one version of the given workflow can active at the same time. By activate the new version other ones will be deactivated.


Workflow export, import

In most cases the developer created the workflows and subprocesses in a developer system. After validation you need to activate the workflow. This function is basically used to move processes between different Effector systems. After selecting the workflow to export and clicking on "Export workflow" button a popup window will ask for confirmation.


In case of a positive response, the system generates an encrypted (AES) file with .wfp extension (the file name is generated from the process name and version number). The file contains the XML and SQL files associated with the given workflow.

You can create a restore point before importing by ticking the proper checkbox.

You can upload the previously exported .wfp file in the popup window after clicking on "Import workflow" button.


It is important to note that an existing workflow cannot be imported into the same system (because of the same object type). In this case you can use the copy function.

Editing workflow

On the right-hand panel, workflow steps can be added and modified, and relationships defined (using drag&drop). After drawing the workflow, clicking on the "Save" button will create the appropriate XML files, the triggers between the steps, and the changes that have been made since the last backup will be finalized.

  • Event (start, end): start and end of workflow
  • Activity: workflow steps
  • Gateway: gateway, decision points
  • Annotation: note for the given object
  • Pool (swimlanes): grouping tasks (e.g. by roles)
  • Group: logical grouping (graphic element, e.g. phases)
  • Message: graphic element without function
  • Data object: graphic element without function


Creating subprocess

Adding the subprocess is done in the same way as adding a simple step. The difference is that "Subprocess" marker on the right hand toolbar is tilted to the other position. After that the subprocesses appear in a drop-down list. Selecting one of these "+" sign will display in the box that this is a subprocess. Double-clicking at this sign opens the subprocess editor screen.


Objects of the inserted subprocesses are copied and involved in the process run. Therefore if the original subprocess is modified, it will not affect the already included subprocesses. Likewise, if an inserted subprocess is changed, it will not affect the original subprocess. You can also add a subprocess to a subprocess, the number of levels is unlimited.

Start an ad hoc subprocess

To start a subprocess in a fragment, you must specify a default value for the WorkflowID field: the ID of the process within which you want to start the ad hoc subprocess.

For events created from the first step of the subprocess, the trigger must be set to CreatedOrDone from Done.

Editing step

The “New step” box on the toolbar can be dragged to the work area using drag&drop. Once released, the new step window will open.


Base data

  • Step name: It's required.
  • Description: It will be the default label of the workflow step. If it is not specified, the value entered in the “Step name” field will be used for this purpose.
  • Automatic step: Step can be automatically set to done after creation (without user interaction)
  • Table name: To store data related to the workflow step. It's optional but can be required when entry fields are defined on the form related to the step.
  • Progress (%): It's optional with value between 0 and 100). It specifies the percentage of completeness of a given step for the whole process. (This can be visualized by parameterization.)
  • Responsible:
    • If the User(s) value is selected in the drop-down list, the people and groups in the database will appear in the Responsible field. As many values are selected, as many copies of the task are created in parallel. The next step is only created after all of the parallel branches are done.
    • If the role value is selected, the roles in the database will appear in the Responsible field. As many values are selected, as many copies of the task are created in parallel. The next step is only created after all of the parallel branches are done.
  • Developer description: It's optional.
  • Meta data: Metadata can be linked to step.



You can configure each dependency on this tab. You can choose which step will follow the current step, and if a decision has been made in the previous step, which value of the given decision will create the actuale step in this particular run. You can add a new prerequisite by pressing the “New Trigger” button. On the right, all the steps associated with the process appear in the drop-down list. When selecting from there if there is a decision point in any steps you can choose one to see the possible values. Choosing the right one will automatically fill the evaluation rule in the "Condition" field (this can be arbitrarily defined).

If two steps (activity) are linked with arrows in the process editor, the trigger is automatically set between the two steps after saving.


The purpose of this tab is to define fields and field level rules.

If you need to record some data for the current step, you can define new input fields for the step form by clicking the "New Group" button. At this point, entering a table name is mandatory, which can only be an alphanumeric text starting with a letter. Optionally, the field name of the field can be specified. If it is not filled, the system will generate one automatically based on the label with deaccent. If a field with this name is already exists, it will postfix "_x" (where x = 1,2, ...). You can also add a separate developer comment to the field.

When you create a process, you can add fields to the process itself (Project fragment) just as you would for steps.

The following types of controls can be recorded in each group:

  • checkbox (database type: BIT)
  • picklist (database type: INT)
  • drop down list (database type: INT)
  • horizontal line
  • label
  • buttons: save, delete, cancel, other action button
  • textbox (database type: VARCHAR (1000))
  • date (database type: DATE)
  • date + time (database type: DATETIME)

Input fields can be deleted from the group by the trash icon next to them. Deleting all input fields will also delete the group itself. Labels can be renamed. The input field type cannot be changed after recording. The new group ID will be a GUID, eg "923ad59f-a699-4800-A988-e2bbe96e96b7".

In case of drop-down list type input field you can specify the datasource of the list on the Field settings tab of the right side. If you choose a source where additional filtering is possible in the value set (eg I want to display items belonging to only one group from the Lookup values), you must specify which elements of the group to display.


If there isn't a given group in the database, clicking on the new value button you can manage the groups and items belong to the groups (create, modify) on the opening window:


In case of Query TextBox type input field you can specify what kind of screen to open after clicking on the control, which item of the selected row is the key (its value is saved to database) and which item will appear on the dropdown list as a value.


If you add an action button, you must enter the button label and select the appropriate action from the drop-down list. The parameters belong for the operations must be defined in the FSYS_ActionButton table. Optionally, you can set whether the system close the window after the operation is completed.


Rules can be defined for each field as well as for field groups by selecting the appropriate one. This can be found on the right side on the "Rule Properties" tab. On the left by selecting a group or an input field (the selected one is framed by dashed line), click on the "New Rule" button on the right to display a list of optional rules:

  • Required: group and field level rule
  • DefaultValue: field level rule
  • value associated with the session, e.g. login user ID (SessionValue): field level rule
  • Visible: group and field level rule
  • Readonly: group and field level rule
  • ValidateRule: field level rule
  • ComputedValue: field level rule
  • ValueBeforeSave: field level rule
  • WorkflowRequired: group and field level rule
  • TouchValueList: field level rule
  • Tooltip: field level rule
  • Warning: field level rule
  • Placeholder: field level rule

Selecting a rule you have to specify the type of rule (Constant, Simple, SQL), the type of return (Integer, Boolean, String, DateTime, Double), optionally the default value of the rule (if the evaluation fails due to some error) and the expression itself to be evaluated. One type of rule can only be added once to the selected item, and then disappear from the list of optional rules. You can delete a rule by clicking on the trash icon on the upper right corner of the rule.


Branches, decision points

Clicking on a gateway bind to step, selection fields defined in the step are displayed on the right toolbar (have to be added earlier on the step edit screen). Selecting one as many outputs of the gateway will display as many possible value of the selected field. When you select another list, the previous outputs are deleted.

If you connect multiple gateways in a row, you can only select a decision point for each gateway that has not yet been selected in any of the direct gateways. Connected gateways in the trigger condition will be evaluated with and connections.

If you define multiple decisions in a process step and connect multiple gateways to the step in a row, the decisions in the gateways are inserted into the trigger of the next step with and connection. A decision can be assigned to a maximum of one gateway.

If a decision was selected for the current gateway, the branch will always exclusive or (XOR). If no decision was selected, the steps will continue in parallel after the gateway. If there is a convergent gateway before a step and the gateway type is set to "inclusive" then the current step will not be created until all of the incoming braches are completed (this is classic await).


Here are some important things to know about process editing

  • Start must not have an incoming branch
  • Stop must not have an outgoing branch
  • Must not connect directly to a stop from a gateway
  • A maximum of 1 pool can be inserted to a workflow
  • Only one arrow can be drawn from an activity (unless it is a subprocess)
  • Only one arrow can be drawn to an activity
  • Activity name must not be blank
  • In case of an instance of a subprocess (inserted into workflow), its entry and exit point cannot be changed. I.e., when editing an instance of a subprocess, the start or end point cannot be linked to another step(s).
Expanding/narrowing work area

By using the mouse wheel, the area can be expanded or narrowed.

Moving the work area

The work area can be dragged by right clicking and holding down the button on the mouse.

Workflow steps tab

This tab will exhibit the generated workflow steps in the usual card view style. It allows users to edit steps and related decisions, conditions and fields.


Workflow test

This screen gives an opportunity to test run workflows: the steps of the workflow launched on the left-hand side can be followed on the right-hand side. Once ready, the workflow can be selected and launched by clicking on the “New workflow” button on the left-hand panel.



After clicking on save, the first step is displayed, while a flow chart appears on the right-hand side visually representing the status of the run process:


When clicking on the first step, a dialogue window opens offering a chance to mark the step as done and displays the added fields:



On the “Workflow tasks” tab, the individual workflow steps are displayed in card view style, arranged by status.


If the workflow is modified in the workflow editor during testing, the XML files have to be saved into the file system to activate the modifications, following which the page has to be reloaded.

  • Last update: 32 weeks 5 days ago
  • Effector