Signavio

Signavio Onboarding Example

In this chapter, modeling using Signavio will be explained using an example. The detailed documentation for Signavio can be found here.





Login into the Signavio


The user email address is used to log into the user profile. If the user doesn't have an account yet, an account for access may be created under “Registration”. In order to do this, a free license is needed. For questions regarding available licenses, please contact the respective administrator.






Create a new business process diagram


Next, a new model must be created. In this model, the process steps are defined. This model is then exported as a process definition.

  1. Select “New”
  2. Select “Human Workflow for system (jPDL)“
  3. A new browser tab opens, in which a new, empty process model is located. This new model may be changed according to the user's needs


Create and edit the process model

The following process should be used as an easy and concrete example to show the modeling possibilities in the system. This example deals with a so-called onboarding/hiring process, which is relevant for every company.

This section describes the basic functions for working with the process models:

  • Working with a new process model
  • Edit process model
  • Open and save diagrams



Model a pool and swimlanes


To start the process model, the active departments and/or company areas should be determined. This is done using so-called pools respectively swim-lanes, also known as lanes. A pool is superordinate organizational unit, which is made up of multiple lanes (representing, for example, departments).

In order to create a pool, the user clicks and drags the pool symbol(1) from the left channel in the modeling interface.

Double-clicking in the area of the pool(2) separates it to the left, a text field appears, with which the pool may be given a title. In this case the pool is comprised of one superordinate company.

This example is limited in scope to two swimlanes (departments)(3). However, any number may be created. To create more lanes, click and drag the symbol for lanes from the left column and release the mouse once the mouse is positioned over the pool description. Now, the lane is integrated into the pool.

The individual lanes may, in the same manner as the pool, be renamed by double-clicking on the lane caption. In this case, a lane is made for the personnel (“Personal”) department and the IT-department (IT).


















Model a start event


Every process requires exactly one starting event in order to clearly define at what point the process should begin. This may be taken from the left column in the diagram surface. In this case, the process begins with the personnel department. As soon as elements are present in the diagram(4), the context-sensitive menu may be used to add new elements. This menu is located to the right of the currently selected element.

The other way to add new elements is to drag the element from the left column onto the diagram surface. A green check appears under the mouse to show if the element can be dropped into its current position on the screen. If not, a red symbol appears. This can be used, for example, to prevent elements from being added on top of one another in the diagram.



Model an activity


For many elements, the caption may be altered by double-clicking on it. In the first step, the command 'Create personal file' should be executed. For this, a activity node for one of the two options must be created, which takes place after the starting event. This activity node must then be connected to the starting event via a transition.


NumberDescription
1Pool shape
2Description of the pool to reflect the greater organizational unit
3Swimlane reflecting subordinated organizational units
4Start event of the process model
5First activity of the process model
6Transition between elements of the process model to reflect the direction of the process

Model an AND Gateway


Using an “AND” junction, multiple process steps will be completed at the same time. All of the given process steps must be completed before the process continues past this parallel-splitting of the process. In this example process, a parallel conjunction, with multiple concurrent activities, takes place after the first activity is completed.

First, the “AND” symbol is dragged from the left column onto the diagram and connected to the activity by means of the context-sensitive menu.

Now, two new activities, one for the personnel department and one for the IT department, are created and connected with the “AND” symbol. It is possible to create more than two parallel activities if necessary. In this example, the personnel department is given the activity “organize workplace” and the IT department is given the activity “create network account”. If the context-sensitive menu of the AND gateway is used to create new activities, these will be automatically linked.

Opened “AND” connections must be closed at the end so that the process can continue to the next activity. For this, a new AND must be added to the diagram at the position there the parallel paths should end.

Now, the process is nearly finished. Before make this apparent through adding an 'End Event' to the appropriate point in the diagram we configure the process furthermore.



Model a XOR Gateway

OR junctions, unlike AND junctions, do not contain parallel paths. Rather, a decision must be made as to which path should be followed. Only the tasks associated with the chosen path will be distributed. The path is chosen by the executor of the previous task before the fork. The choice is supplied to the system through a pop-up window.

In order to expand the example at hand, the ending event is deleted by selecting it, then using the 'delete' symbol in the Signavio's uppermost editing strip.

Next, the area of the pool has to be expanded in order to accommodate the next steps in the process. This is done by clicking on the pool, then dragging the lower corner of the window until the desired size is reached.

Now, an XOR Element is placed following the AND element. In order to clarify what decision is to be made, the element may receive a caption (i.e. Hardware needed?). A closing XOR is then added to end the process.

Because the process must now make a decision as to which path to follow, it is possible to label both paths in order to clarify which path belongs to which decision. The two arrows may be labeled by double-clicking on them. In this case “yes” leads to 'Archive personal file' and “no” leads to the activity “Order hardware”.

In order for the system to properly determine which path should be taken, the attributes must be properly tended to. For this, the attributes menu of the arrow must be opened and given a technically unambiguous name in order to make the assignment clear.



Model script or mail node


The activity 'Archive personal file' in the process model can be done automatically by the system without the need for user interaction. Therefore the type of the activity has to be changed. For changing the type, click on the activity. A tool kit will appear, clicking on the wrench button opens a menu. Pressing the 'Node' button will change the activity to a script node with an scrip symbol placed within the activity on the upper left side.

In order to change the activity to a mail node simple click the 'Mail Node' instead of the 'Node' button and an envelope on the activity in the upper left side will indicate that the activity changed to a mail node.



Model an end event


Finally, we end the process by adding the end element from the shape repository and connect all open transitions to the end event.



Save a process model


In order to save the process model navigate to the disk symbol in the upper left navigation menu. On the opening drop-down click the 'Save' button and choose a name and location for the storage of your model.





Defining and editing automation attributes


This paragraph explains how to set attribute values while using the attribute editor. Using a column on the right edge of the editor, the attributes may be customized. The button may be used to show or hide the attribute menu. Now, the attributes of the selected object within the process can be shown. If no object is selected, the general process attributes will be shown.



Attributes of the process model


Process attributes must be created. It is also important that the process receives a distinct name. The attribute owner, starter, and deployer must also be designated.

By clicking on an empty position within the diagram, the process attributes may be edited. Now, the rolls must be assigned. Lastly, the role distribution must be defined within the swim lanes. This is also done using the attribute menu, found by clicking within the desired swim lane.


AttributesAttribute Description
DescriptionDescription of the process, which will later be shown in the system (tooltip and process report).
Starter MandatoryHere a group or a user, who is allowed to start instances of a process definition, e.g. user(john.doe), group(pm) is entered.
Owner MandatoryHere a group or a user who “owns” the process in the system is entered. “Owner” means that this person is responsible for the process
Deployer Mandatory Here a group or a user as workflow-designer who as workflow-designer is allowed to deploy the process in the the system system is entered.
Smartform

Here the definition of the smart form is entered.



Attributes at start event


The system specifications show only a portion of the attributes, which can be changed using the attribute editor. In any case, only a few of the attributes have any noticeable effect.


Attributes

Attribute Description

Name MandatoryDescription of the process, which will later be shown in the system (tooltip and process report).
Starter MandatoryHere a group or a user, who is allowed to start instances of a process definition, e.g. user(john.doe), group(pm) is entered.
Owner MandatoryHere a group or a user who “owns” the process in the system is entered. “Owner” means that this person is responsible for the process
Deployer Mandatory Here a group or a user who as workflow-designer is allowed to deploy the process in the system is entered.
Form Definition

Here the definition of the smart form is entered.



Attributes at swimlanes


In addition each swimlane needs to be assigned to a user or group. The 'Attribute' can be altered by clicking on the swimlane header and altering the respective properties on the right side.



Attributes at activities


General configuration options

In essence, every activity must have a unique name and at least one task attached to it. Optional working time may also be included. Firstly, the activity attributes 'Create personnel file' is edited. For this, the activity must be marked and the attribute bar must be used. The previously-given name will be adopted in this window.


Attribute name

Attribute Description

NameDescription of the activity
DurationHere the duration in which the tasks of this activity must be completed can be entered. 
TasksBasically every activity must have its own unique name. If no task is explicitly defined for the activity, the system generates a task with the name of the activity. With the aid of the automation properties menu one or more tasks may be added for an activity.
EventsHere events can be entered. Events or ActionHandler are special functions that are executed as soon as a specific process step is reached or left.


Add processing times to an activity

The processing time can be entered in each process activity. It specifies how long the employee may need for the tasks within an activity until they have to be finished.  Open the 'Attributes (Task Node)' of an activity via clicking on the activity. Enter a processing time for this activity into the field 'Duration' in the area 'Main Attributes'.

The format in which the duration has to be entered: HMM - like 830 = > 8 hours 30 Minutes.


Adding a task to an activity

A task must be created within an activity in order to be able to be completed once deployed to the system.

To achieve this click on the drop-down 'No values' next to Tasks. A pop-up window appears. By clicking on “add” a new task can be entered. Any number of tasks may be created, all of which must be completed before the activity is counted as complete. This step must be followed for all activities.


AttributesAttribute Description
NameDescription of the process, which will later be shown in the system (tooltip and process report).

Duration

Mandatory

Entering and changing of time durations. Format: HHMM

Ex.: 1 hour = 0100, 10min = 0010

Task

Mandatory

Using the dialog behind the points, multiple tasks may be given for a single activity.
Events Here, so-called ActionHandlers for the activity may be integrated.


Add events to an activity

Events are special functions that can be executed as soon as a certain process step is reached or left. These events are called ActionHandler and the system supports a whole range of pre-made ones. The list of ActionHandlers can be viewed here. Events can also be added to Script Nodes. A detailed description is given in paragraph 'Attributes at script nodes'.

Attributes at mail nodes


The Mail node is a simple function to send standard emails in the system. These can be emails to external individuals and groups, as well es notifications to process participants and decision-makers. These emails can contain process information or prompt specific user to complete a task in the system. In Order to add attributes to the mail node left click on an activity, via the wrench symbol click on the 'Mail node'.


The activity will change to a mail node with a envelope symbol on the upper left of the node. In the 'Attributes (Mail Node)' the parameter can be added.


Attribute name

Attribute Description

NameThe Description of the Node can be altered here.
ToThe recipients can be defined here. On the one hand, groups and user definitions (group (NAME_DER_GRUPPE) / user (NAME_DES_USERS)) can be used again. The email can also be sent to the current processor of the Swimlane "HR". In addition, fixed e-mail addresses or distribution lists can also be used here (e.g. it-asset@yourcompany.com).
SubjectThe subject of the email can be freely assigned. In this example, a variable is also referenced (the name of the process run). These variables can be used in the subject or in the text and are always masked with a $ {…}. As soon as the email is sent, the variable placeholders are replaced by their actual value. Further information on the variables can be found on this page.
TextThe email text can be designed in any way. Variables can also be used. The sending of HTML email and other settings are explained on this page.


Attributes at script nodes

ActionHandlers or events are special functions that are executed as soon as a certain process step is reached or exited. There are a number of pre-made ActionHandlers. New ActionHandlers are often created for special functionalities in projects. The maintenance of ActionHandlers in the process is always the same. In this section, two events are maintained exemplary. As an example, a process run should be renamed automatically. A unique consecutive number should be generated and used. Two ActionHandlers are required:

  • YearIdGenerator: Generates the consecutive numbers and saves them in a process variable
    RenameInstanceHandler: Uses the sequential number/process variable and builds this into the new name of the instance


The following figure illustrates this process:



This logic is now built into the process. First, you have to decide on which process step such an event should be carried out. For this example, of course, it only makes sense to rename it at the very beginning. For this, we use the first activity 'Create personal file' and set up the ActionHandlers on 'node-enter'. This means that the name of the instance is displayed correctly from the very first task.

First, the activity must be selected and the 'Attributes (Task Node)' opened. The first thing to add in the popup is a new event (see figure) by clicking the 'Add' button.

The ActionHandler must now be parameterized in the next view. The basic settings for an event can always be found on the associated documentation page (YearIDGenerator). The picture shows the parameterization for this example. The event generates a consecutive number and saves it in a variable called "newNumber". The number can then be addressed in the second ActionHandler using this name.


Attribute name

Attribute Description

Event TypeSpecifies whether the ActionHandler should be executed when the activity is reached (input node) or when it exits (output node)
Action NameCan be chosen freely. Serves for a better overview of the list of events
Action ClassDefines which ActionHandler is to be executed. It can be copied from the wiki page.
Mandatory FieldsDepending on the ActionHandler, either "Mandatory fields" or "Parameters" must be passed. The description can be found on the wiki page. No parameters are required for this ActionHandler. You only have to enter something in "mandatory fields". 
ParametersSee above.
OkSaves the attributes to the script node of the process model


The event has to be saved in the script node of the process model. A new event must then be created (RenameInstanceHandler) for the current example. However, parameters are required for this ActionHanlder. To do this, click into the empty row belonging to the column 'Parameters' after having added a new event. A pop-up will appear where the required parameters can be added.

According to the documentation, only one parameter has to be added to this handler (instanceName). The value of the parameter can be used to specify how the name of the new instance should be composed. Static values ​​can be entered or values ​​from variables. To access such variables, the mask "$ {...}" must be used. In this case, we want to access the previously created process variable "newNumber".

After saving the parameters and the event, the following list should appear with the two ActionHandlers. The order of the ActionHandlers plays an important role. They are executed from top to bottom.

This order is important when ActionHandlers, as in our example, are build on each other.




Deployment Check

Before a process is released, a deployment-check may be run. This proofs if all of the settings needed for a successful deployment have been made and if the process is viable to run in its current state. The deployment check is run by clicking on the corresponding button.


Now, various symbols are blended into the process graphic. By running the mouse over the symbols, erroneous areas may be identified.

There are two types of messages:

Warning: indicates that the model is not yet complete. For instance, if no duration was attached to a task. This has no effect on the success of the deployment step, but rather gives tips on how to increase the quality of the process.
Error: indicates that an essential step was not completed, for instance, that a roll assignment was not defined or an element was left unnamed.

The process is thus not allowed to be deployed in the system.

Once all warnings and errors have been addressed the check will be successful.





Deployment to the system

The process deployment in the the system-mask environment occurs after the option “Deploy to the system” has been selected from the menu. In order to deploy the process, the user must have the role of workflow-designer in the system user administration.

After giving the endpoint, username and password, the process is deployed by clicking on the button “deploy”.



On this page