The process configuration is used to define specific global processes that cover a the management of (a part of) an educational object from start-to-end.
An example of a process definition is the process for the change and approval of courses, including all steps and stakeholders involved in the process.

The menu-option Processes opens an overview of the defined processes.

Processes can be managed using the Add, Edit (select) and Delete buttons.
The first step is to define the Process and its generic behaviour.

Different definition and configuration are supported:

• Type - Object type the process is designed for. Supported types are:
  - Faculty
  - Organisation
  - Specification
  - Study
  - Module group
  - Module
  - Assessment
  - Method
  - Qualification
  - Team
  - Person
• Name - Internal name of the process
• Label - The descriptive text for the workflow, as shown to the user on the personal Dashboard and in reporting and process management.
• System - Define the default system the 'approved' result should be sent to. The system configuration can be used to identify the destination, but can also be used as a filter mechanism to exclude certain educational objects.
• Condition - Define a condition that specifies the objects must meet for this process
• Show only when offered - Define the rule used in case a process is based on offering periods instead of a fixed start- and end date.
  Options supported:
  - Offering period ends in
  - Offering period starts in
  - Offering period overlaps
• Sequence - Order the process is shown in the reporting and process management overview
• Start Date - Date from which this process configuration will be valid
• End Date - Date till which this process configuration will be valid

Based on the setting the process wil be started for the relevant educational objects that meet the criteria.

• Start upon creation of an object - Indicator if the process and relevant tasks must be created automatically on creation of a new object of the defined Type.
• Start on start date - Indicator if tasks must be created automatically on the defined process start date, or a process manager fill launch the process.
• Start allowed by participant - Indicator if a participant of a process is allowed to start that process for an individual education object.
• Show progress on dashboard - Indicator that will show the progress of this process in the Process progress Dashboard widget.
• Show terminated objects - Indicator if the task is shown after the deadline is past
• Reject should always be possible - Indicator if the user is allowed to reject to all of the previous defined states in the process, or only to the defined route / options.
• Approve should allow multiple options - Indicator if the user is allowed to approve to all of the defined states in the process, or only to the defined route / options.
• Hide inactive statuses - Indicator if inactive statuses in the workflow should be hidden or shown (default)
• Allow email to users with role on parent entity - Allow sending of notifications to any user in the hierarchy, e.g. sent to study coordinator if its a module process.

After finishing the basis configuration of the process, the next step is to define the process statuses and transitions.

First define the statuses the process consists of. In the example below the process consists of 5 statuses.
Each status is assigned a workflow and a stakeholder. Based on the status of the process, the defined stakeholder will get a task on the personal dashboard.

Use the Add, Edit and Delete options to manage the statuses.

Different definition and configuration are supported:

• Name - The internal AscMe name of the status. There is a limited number of predefined statuses that can be used in the definition of the process flow.
• Label - The name of the status as shown to the user.
• Order - The order of the status in the process.
• Icon - Assign an icon to the process that is shown in the Task Header on the personal dashboard.
• Color - The color assigned to the status will be used in the reporting screens.
• Condition - Expression (rule) to define a condition to only start the process for the (in this case) modules that meet the condition.
• Hook - A specific hook (technical action) that should be executed once this status is reached.
• Workflow - The workflow assigned to this status that will provide the dedicated 'wizard' support for the responsible task executor.
  ‍
  This step is easily forgotten!
  Depending on the working order, the configuration may start with the process configuration. In that case the workflow is not yet available and cannot be assigned.
  First after configuration of the workflow (menu-item workflows) the defined workflow can be allocated.
  ‍
• Owner - The owner (role) of the process, used to override the stakeholders defined at workflow level
• Days until deadline - Show a visual indicator on the personal dashboard in case the process deadline is less then the configured days
• Skip - Indicator if the workflow can be skipped by the task responsible user, so no data is validated or entered.
• Skip if no participants - Indicator if this status can be skipped in case no 'task responsible user' is defined.
• Reopen - Indicator if the user is allowed to reopen the process to this task
• Exportable - Indicator if the process is in a status it can be 'sent' as approved to other systems like an SRS by an authorised user (f.i. process manager)
• Export automatically - Indicator if the process has reached a status it will automatically be sent to other systems like an SRS

Notifications can be sent out when the next step or configured date is reached. The default behaviour is that this will happen immediately.
The administrator can configure the time the notification(s) are send, e.g. at night, via the administrator menu-item Script.

In the status overview use the notification button to manage the automatic sending of notifications.

Click on a defined notification or use the + or delete button to manage the notification.

Different definition and configuration are supported:

• When - The used event or date to trigger the sending of the notification
  - Date end: The notification trigger will be based on the defined end date of the process.
  - Date start: The notification trigger will be based on the defined start date of the process.
  - On reopen: The notification trigger will be executed if the process is restarted.
  - On start: The notification trigger will be executed if the process is started
• Before/after - In case of start / end date, this specifies the relative days from that day.
• Template - The notification template to use.
  Notification templates can be modified/added by the administrator via the menu-item notifications.
• Role - Recipient of the notification. The person(s) assigned to the role on a specific object (f.i. module responsible on a Module).

The flow in the process is defined via status transitions. They define the transition in the process from the source status to the target status.
The example below shows a configuration of transitions in the earlier used curriculum management process.

Use the Add, Edit or Delete button to manage the transition.

Different definition and configuration are supported:

• Source - The status the transition starts from
• Target - The status the transition goes to
• Description - Additional information shown on the transition submit page to the user
• Comments - Indicator how comments are handled during transition from the source to the target status:
  - Never (no option to add comments is added to the user)
  - Optional  (the user can choose if comments are filled)
  - Required  (the user has to enter a comment)
• Hook - A specific hook (technical action) that should be executed once this status is reached.

The transition overview, shown in the section above, supports the definition of propagations for a specific transaction.

A propagation is used in case the status change is not only restricted to the current process, but should also start a new process.
Click on the [ + ] to add one or more propagations. The target is the process and its status that will be started for this object.

The example below shows the statuses defined in a process that supports the request for a new study, including validation by marketing and sales.

In this process a status transition is defined from an approval status to the approves status.
On this transition a propagation can be defined that will automatically launch the curriculum design task on approval.

The administrator can add a propagation and select the process and status of the started process.

The final step is to define the process running parameters. These parameters are used to define the 'opening period' for the defined process.
The bar shows the progress and number of days left until the deadline.

‍

Use the Add button to define a new 'running period'.
For annual processes each year a new process should be configured that is bound to the academic year.

Different definition and configuration are supported:

• Period - If a process is defined as bound to a period, the period can be selected this process will run for.
  This option can be used to gather scheduling preferences for modules based on semester (twice a year).
• Start - Start date of the process, indicates when tasks will be created automatically (if configured so) and will be available in the user personal Dashboard.
• Deadline - End date of the process, used for notifications that can be sent relative to deadline.If not configured tasks are still available after deadline the tasks will no longer be available for the user in the personal Dashboard.
• Last shown - The date on which the tasks will definitively be removed from the user personal Dashboard, even if 'show after deadline' is set.

In case for specific faculties a different timing should be used this can be configured, as shown in the above example.
The Biosciences faculty is excluded from the process and the Social Sciences faculty is running the process in a different time frame.

Click on the faculty to configure a different timing from the configured default.

Different definition and configuration are supported:

• Start date - Start date of the process, indicates when tasks will be created automatically (if configured so) and will be available in the user personal Dashboard.
• End date - End date of the process, used for notifications that can be sent relative to deadline.If not configured tasks are still available after deadline the tasks will no longer be available for the user in the personal Dashboard.
• Ignore - Exclude this faculty from the process

The process configuration allows the option to inform the various stakeholders via notifications. These configured notifications are a notification template with [tags] that are replaced with actual data sending the actual notification to a user.

The notification template menu is used to manage the notification templates.

Select a template or use the Add or Delete button to manage the template configuration.

Different definition and configuration are supported:

• Template name -The name of the template, shown in the selectbox in the workflow configuration
• Notification title -Subject of the notification/mail send
• Trigger -Specifies how this notification will be triggered, supported values are:
  - Workflow notification: notification can be used in the workflow definition
  - Manual: notification can be send by a user
  - Individual change rejected: notification is used as a reply to the user that proposed a change in case a proposed change is rejected
  - Reply to comment: notification is used as a reply to a comment on a proposed change or another user comment
  - Module terminated: notification if a module is terminated

• Notification contents - The notification body to be send. The notification text can be defined containing specific [tag] / placeholders.
  During the sending process the placeholders are replaced by the actual value.

Not shown:

• Send online -Indicator if the notification is sent within the system, and shown on the dashboard (bell icon)
• Send by email -Indicator if the notification is sent by email
• Urgent -Indicator if the notification should be sent with an urgent indicator
• Style -Specify a style to be used to style the notification

Information on the available [tag] / placeholder is available via the (i) icon.
Supported placeholders are:

• recipient name
• name of object
• workflow name
• process name
• status name
• link to dashboard
• link to object's page
• days remaining to perform action
• Date the task should be finished

The definition of processes and process transitions provide the option to execute a hook (a piece of logic (functionality)).

The system allows for the configuration of hooks that can be selected during process configuration. The hooks can be configured via the menu Hooks.

Use the Edit, Add or Delete button to manage the hooks.

The definition of the hook is straight-forward. First select the type / name of the hook and then provide the description that is used in the process configuration.

Different type of hooks are supported:

• Approve cost divisions -
• Clean activities -
• Clear publication date -
• Combine hooks -
• Complete advices -
• Complete cost divisions -
• Export data -
• Set field value -
• Set publication date -
• Sync module methods -