Skip to main content
Version: 16.0 (Preview)

Component Settings

The Component Settings page allows you to customise a wide range of library-specific features. Component settings provide a basic configuration for components such as release workflows, validation functions, and more. If a component has multiple configurations or templates, you can find and modify them here. The component settings are stored in the ADONIS database and can be migrated between different ADONIS versions to preserve your settings.

The Library Management page shows all component settings in the database. Depending on the ADONIS configuration, different components can be available for configuration.

Manage Component Settings

Component Settings can be imported, exported, deleted, and more.

Import Component Settings

Component settings previously exported can be imported and stored in the ADONIS database.

To import component settings:

  1. Go to Component Settings > More options, and then click Import component settings.

  2. Click Browse and select the file you want to import. You can also drag a file from your computer to the Drag and drop files here to upload area.

  3. Select the component settings you want to import. Alternatively, you can select Import all component settings at the top to import all settings at once.

  4. Click Import. When prompted to continue, click Yes. The data is imported.

When the import is complete, a success message appears. Close the message to complete the process.

note

Behaviour if a configuration (e.g. "General") already exists in the database:

  • If a configuration already exists in the target library, it is overwritten with the contents of the import file.

  • Configurations that do not already exist in the target library are added.

  • Configurations that exist in the target library, but not in the import file, are not changed.

Configurations for web modules are an exception. The information from both sources is combined:

  • If a web module exists both in the source library and the target library, it is overwritten with the contents of the import file.

  • Web modules that exist in the target library, but not in the import file, are not changed.

Export Component Settings

Component settings can be exported from the database and saved into an AXS file in the file system. This is useful to e.g. migrate chart templates which you have created to another ADONIS version.

To export system roles:

  1. Go to Component Settings > More options, and then click Export component settings.

  2. Select the component settings you want to export. Alternatively, you can select Export all component settings at the top to export all settings at once.

  3. Click Export. The data is exported.

ClamAV Virus Scanner

By integrating the ClamAV virus scanner into ADONIS, files being uploaded to the ADONIS database (documents, media files, files attached to comments, etc.) or downloaded to your device may be checked for virus infections.

note

For detailed instructions on how to integrate ClamAV into ADONIS, please refer to the chapter Enable Virus Scan for File Uploads in the Installation Manual.

Common

In this area you manage configuration options for the following general settings:

Document Management

Using the Document Management settings, you can configure an object type which allows web client users to upload documents into the database in order to use them in models. By default, the imported files are maintained as objects of the type Document in the Object Catalogue.

When a repository is exported for backup and migration purposes, the documents are exported as well.

Open Document Management Settings

To open the Document Management settings:

  • Go to Component Settings > Common > Document management.

Configure Document Management

The following settings are available:

  • Activate Document Management

    Select or clear this option to turn uploading documents on or off. All other options in this area will be inactive unless you select this option.

  • Class for Document Management

    Select a class for the document management from the drop-down list.

  • Attribute for Document Management

    Select an attribute for the document management from the drop-down list.

  • Max file size (MB)

    Select the allowed maximum size for documents in the database (up to 50 MB).

  • Allowed file types (space-separated extensions)

    Select the allowed file types for documents in the database. Separate the file extensions with a blank.

    Allowed file types include: doc, docx, ppt, pptx, xls, xlsx, csv, txt, pdf, rtf, png, jpg, gif, jpeg, bmp, zip, rar, 7z, axr, xml, bpmn

    All other file types are blocked by default. To allow additional file types to be added to this list, you need to customize a configuration file.

info

The ADONIS application server has to be restarted if these settings are changed. Otherwise the changes will not become effective.

Media Management

Using the Media Management settings, you can configure how web client users are allowed to upload images to the database in order to use them in models. The images are referenced in the attributes of certain objects (Notes and Cross-References) and displayed in place of these objects in the graphical editor.

When a repository is exported for backup or migration purposes, the images are exported as well.

Open Media Management Settings

To open the Media Management settings:

  • Go to Component Settings > Common > Media management.

Configure Media Management

The following settings are available:

  • Activate Media Management

    Select or clear this option to turn uploading images on or off. All other options in this area will be inactive unless you select this option.

  • Attribute for Media Management

    Select an attribute for the media management from the drop-down list.

  • Editable for repository objects

    This option only becomes relevant in specific customising scenarios. Enabling this option and adding the attribute for the media management to the Notebook of a repository class enables you to set a global value for the media management attribute across all model contexts.

  • Max file size (MB)

    Select the allowed maximum size for images in the database.

  • Allowed file types (space-separated extensions)

    Select the allowed file types for images in the database. Separate the file extensions with a blank.

info

The ADONIS application server has to be restarted if these settings are changed. Otherwise the changes will not become effective.

Object Owners

In ADONIS a user can be assigned ownership of a repository object (e.g. Applications, Processes etc.). In order to do so, the user has to be assigned as Responsible Person (object attribute in the Notebook chapter "Organisation").

note

Alternatively, you can select a different relation to define ownership.

The object owner is responsible for the content of the object.

Open Object Owners Settings

To open the object owners settings:

  • Go to Component Settings > Common > Object owners.

Configure Object Owners

The following settings are available:

  • Set the user automatically as object responsible after creation of objects

    Select whether a user who creates an object is automatically assigned as its owner.

  • Relation class that should be used to define an ownership

    Select a relation class as default ownership relation from a drop-down list of all ownership relations in use in the current library. This relation is then used e.g. to create ownership between an object and a user when the user creates a new object and the first option is enabled.

    [OOO]

    When you select a relation class with the suffix [OOO], the object owner will get granted write access to the object. What type of access they had previously usually has no effect. Only metamodel rights take precedence over permissions set by an [OOO] relation.

    After the assignment, ADONIS Administrators can adjust the rights of object owners as they see fit. When the reference to the user is deleted, rights to the object are inherited as set in a superior hierarchy level (group).

  • Show responsible user in search results in the Web Client

    Select this option if you want a column with the object owner to be displayed by default when search results in the web client contain repository objects.

info

The ADONIS application server has to be restarted if these settings are changed. Otherwise the changes will not become effective.

Data Actuality

Keeping your data up-to-date is crucial, and that's why we've made it easy for users to confirm the data actuality of objects in the web client.

You can customise the data actuality assessment by selecting the attribute on which it should be based. Additionally, you can set thresholds that will trigger a 'yellow' or 'red' flag if an object's data actuality has not been confirmed.

Open Data Actuality Settings

To open the data actuality settings:

  1. Go to Component Settings > Data Actuality > General.

General settings

The following settings are available:

  • Attribute for Data Actuality

    Select the attribute on which the data actuality assessment should be based.

Global threshold

Here you can set global thresholds for assessment of data actuality. These settings apply to all object types if no class-specific values have been defined.

  • Number of days after which an object is marked 'yellow'

    Select after how many days an object is marked as 'yellow' if its actuality was not confirmed by the user responsible for this application.

  • Number of days after which object is marked 'red'

    Select after how many days an object is marked as 'red' if its actuality was not confirmed by the user responsible for this application.

Class-specific thresholds

Here you can override the global thresholds by setting individual thresholds on specific classes.

  • Select after how many days objects of a specific type are marked as 'yellow' or 'red' if their actuality was not confirmed.

Integration - Configuration

The ADONIS integration framework is a generic ADONIS extension that can be used to create and configure adapters connecting to any kind of third party tool that exposes an HTTP interface which allows fetching of data.

note

A detailed description of this functionality is beyond the scope of this manual. If you have questions, please contact your ADONIS consultant.

Model Release Workflow

ADONIS provides a model release workflow management system which allows to formalise model release and versioning. During the release process contributors carry out different tasks depending on their system roles.

note

The availability of the model release workflow depends on the licence.

Set up Access to Model Release Workflow

You can use the default configuration of the model release workflow or a user-defined configuration.

Default Configuration

To use the default configuration, add users to the following system roles depending on their task in the release process. These are sub roles of the system role "Model Release Workflow":

  • Modellers create and submit models to review. They can also create new versions of models which have already been released in order to adapt them.

  • Reviewers perform methodical reviews [system role reviewer (methodical)] and business reviews [system role reviewer (business)] of the submitted models.

  • Administrators can execute all transitions. They are responsible for the maintenance of the release process. Only Administrators can manually archive models (when a new version of a model is released, the previous version is archived automatically).

Afterwards the model release workflow is ready for use.

User-Defined Configuration

To use a user-defined configuration, the following steps are necessary:

  1. Configure the model release workflow. Add new system roles (e.g. A, B, C, …) on the Configure Roles page.

  2. Add users to the appropriate system roles depending on their task in the release process.

Afterwards the model release workflow is ready for use.

note

Please refer to the section Manage System Role Members for details on how to assign system roles to users.

Configure Model Release Workflow

To configure the model release workflow:

  • Go to Component Settings > Model Release Workflow > General.

The model release workflow configuration wizard has 5 pages:

  1. Configure Mapping

  2. Configure States

  3. Configure Roles

  4. Configure Rights

  5. Configure Transitions

These pages are discussed in more detail in the following sections.

Configure Mapping

The first page of the model release workflow configuration wizard allows you to select model types, model references and attributes.

caution

Do not use metamodel rights to restrict access to attributes configured here, as these attributes are required for the model release workflow to work.

You can view and edit the following data:

Main Configuration

  • In the Configuration name area, edit the language-specific names of the model release workflow for all languages ADONIS supports. These names are visible on the user interface, e.g. in the state filter.

Model Type Selection

  • Select the model types that should be available for use in the model release workflow.
note

When you configure a specific transition, you can specify for which model types that transition is enabled. However, you can only select from the model types made available here.

Version Configuration

  • Define the minor version format and the major version format which is assigned to models during versioning.

Prolongation Configuration

  • To turn the prolongation functionality on or off, select or clear the Active check box.

  • In the Daily validity check at (hh) box, type or select the hour of the day (in 24-hour time format) when the validity of all versioned models is automatically checked on the ADONIS application server. The default setting is each night at 1:00 AM local time.

Version History Functionality

  • To turn the Version history functionality on or off, select or clear the Active check box.

  • Select the Maximum entries in the version history. When this sum is reached, the oldest entries are removed from the table.

Process Responsible Functionality

  • To turn the Process responsible functionality on or off, select or clear the Active check box.

  • Select the Process owner, the Process manager, the Methodical reviewer and the Process analyst/designer attributes. These attributes represent the stakeholders who are responsible for a process.

  • The attributes Additional responsible 1, 2 and 3 allow you to define up to three additional attributes representing process representatives.

note

If process responsible functionality is activated, you can define various conditions, checks and actions which are otherwise not available. You may e.g. specify that only models with a Process owner defined in their Notebooks can transition to a new state.

After you have completed these settings, select page 2 from the navigation menu at the top to advance to the next page of the model release workflow configuration wizard.

Configure States

The second page of the model release workflow configuration wizard shows all states in the workflow, along with their details. You can edit and create new states.

The following options are available:

  • Edit State

    To the right of the state, click More, and then click Edit. Now you can configure the state.

  • Delete State

    To the right of the state, click More, and then click Delete.

  • Add State

    Click Add new state. Now you can configure the state.

  • Change Order of States

    Use the icon with three horizontal lines to the left of a state to drag it to a new position.

note

You can edit some status details inline directly on the Configure States page, namely Type, Icon, and Colour.

Edit or Add Transition State

When you add or edit a state on the Configure States page, a form will appear. You can view and edit the following data:

Language Independent Name

  • A language-independent name that uniquely identifies the state is applied automatically based on the enumeration values of the State attribute.

Language-Specific Names

  • Edit the language-specific names for all languages ADONIS supports. These names are visible on the user interface.

Icon

  • Edit the state icon directly in the text box. If the ADONIS web client is installed, you can find a full list of icons by adding /fonts/awesome/icon-index.html to the URL of the web client, e.g. http://localhost:8000/ADONIS16_0/fonts/awesome/icon-index.html. The keyword "axw-fa " (space after axw-fa) has to be added as a prefix to the icon name.

Colour

  • Edit the colour of the state icon and the colour of the state in pie charts. Click the colour circle and choose a colour, or enter a specific Hex colour value manually.

Type

  • Select the predefined state type that corresponds to this state. State types include logic for the interplay with the process release workflow, validation checks etc. Each state type bundles certain release workflow behaviours.

    • "Draft": Select if the state represents draft versions of models. In models with a state of the state type "Draft" it is ensured that the contained versioned objects are automatically present in the latest released version or draft version. Contained objects are updated when there is a new draft version or when there is a new released version.

      Example

      When you create a new draft version of a Process, the new object replaces the original object in all Process Landscapes that are in the state "Draft".

    • "Review": Select if the state represents models that are currently being reviewed. In models with a state of the state type "Review" it is ensured that the contained versioned objects are automatically present in the latest released version.

    • "Released": Select if the state represents released models (released, valid etc.). In models with a state of the state type "Released" it is ensured that the contained versioned objects are automatically present in the latest released version.

    • "Archived": Select if the state applies to archived models. The state of the contained versioned objects does not change in models with a state of the state type "Archived". Archived objects remain archived and are not replaced by new released versions.

State as Model Group

  • Select Represent state as model group to have models cycle through folders with the name of the current state during versioning. All other options in this area are inactive unless you select this check box.

  • From the Use model group of the referenced state list, you can reference another state. Models in the current state will now appear in the model group of the referenced state.

  • Click Custom group name to specify a custom name for the model group. Enter a language-specific name for every language ADONIS supports.

Example "Represent state as model group"

Models in the states "Under methodical review" and "Under business review" should appear in the same custom model group ("Under review"). To do this, follow these steps:

State "Under methodical review"

  • Activate the option Represent state as model group.

  • The Custom group name is "Under review".

    "Under business review"

  • Activate the option Represent state as model group.

  • From the Use model group of the referenced state list, select the state "Under methodical review".

After you have completed these settings, select page 3 from the navigation menu at the top to advance to the next page of the model release workflow configuration wizard.

Configure Roles

The third page of the model release workflow configuration wizard shows all system roles specific to the release workflow (= RWF roles or release workflow roles). You can edit and create new roles.

note

Add the users to the appropriate system roles depending on their tasks in the release process.

The following options are available:

  • Edit Role

    To the right of the role, click More, and then click Edit. Now you can configure the role.

  • Delete Role

    To the right of the role, click More, and then click Delete.

  • Add Role

    Click Add new role. Now you can configure the role.

  • Allowed to Create New Models

    Select Allowed to create new models so that users with a specific role can create models of those model types for which the model release workflow is enabled. Note that this setting only applies to model types that are part of the release workflow and has no effect on other model types.

Edit or Add Transition Role

When you add or edit a role on the Configure Roles page, a form will appear. You can view and edit the following data:

Language Independent Name

  • Enter a language-independent name that uniquely identifies the system role.

Language-Specific Names

  • Edit the language-specific names for all languages ADONIS supports. These names are visible on the user interface

After you have completed these settings, select page 4 from the navigation menu at the top to advance to the next page of the model release workflow configuration wizard.

Configure Rights

The fourth page of the model release workflow configuration wizard allows you to set access rights to models in the model release workflow depending on system role and state.

Access Rights for Models

  • Select access rights to models in each state from the corresponding drop-down lists.

You can define access rights for every release workflow role and for users without a release workflow role ("All others").

note

Users without a release workflow role should not have write access to release workflow models, because they can use it to override the mechanisms of the release workflow.

The following types of access are available:

  • Read

    The user can access this element but is not allowed to make changes.

  • Write

    The user may use, modify, save, and delete the element as they want.

  • Read Models with Translation Option

    The user may not modify the model in structure and size, but they may translate existing attribute values into other content languages.

  • No Access

    This element is not available for the user (it is invisible for them in the various lists and catalogues).

  • Default Rights (Inherited)

    Permissions for models as set at the level of user groups or directly at the user level apply. See Rights Management for details.

After you have completed these settings, select page 5 from the navigation menu at the top to advance to the next page of the model release workflow configuration wizard.

Configure Transitions

The fifth page of the model release workflow configuration wizard lists all transitions in the workflow. For every transition, the source state of the model before the transition and the target state of the model after the transition is shown. You can edit and create new transitions.

The following options are available:

  • Edit Transition

    To the right of the transition, click More, and then click Edit. Now you can configure the transition.

  • Delete Transition

    To the right of the transition, click More, and then click Delete.

  • Add Transition

    Click Add new transition. Now you can configure the transition.

  • Change Order of Transitions

    Use the icon with three horizontal lines to the left of a transition to drag it to a new position.

Edit or Add Transition

When you edit an existing transition or add a new transition, a dialogue window containing the following tabs opens:

These tabs are discussed in more detail in the following sections.

General Settings

The General Settings tab contains the following settings:

  • Edit the language independent name and the language-specific names of the transition directly in the respective text fields.

  • Select whether ADONIS should create a menu item for the transition on the user interface.

  • When you execute a transition in the web client, the state icon of the target state is displayed in menus and in the "Control & Release" dashboard. To replace the state icon with another icon, edit the Icon (overrides the target state icon) directly in the respective text field. If the ADONIS web client is installed, you can find a full list of icons by adding /fonts/awesome/icon-index.html to the URL of the web client, e.g. http://localhost:8000/ADONIS16_0/fonts/awesome/icon-index.html. The keyword "axw-fa " (space after axw-fa) has to be added as a prefix to the icon name.

Configure States

  • Configure the states of the transition:

    • Select source state and target state lets you select one or more source states and a target state.

    • Initial transition means that the status of a model which has no source state changes to the initial model release workflow status (e. g. "Draft") when this transition is carried out.

    • Transition is valid in each state means that this transition can be carried out regardless of the source state of the target model.

note

When a transition is configured to be an initial transition, notifications are disabled.

note

When a transition is configured to be valid in each state, all actions are disabled and reset except:

  • History settings

  • Show success message for transition

System Transition

  • For certain scenarios it is necessary that transitions correspond to a certain type. Each system transition brings some logic with it. At the moment, ADONIS supports the following types of system transitions:

    • No entry: This setting is disabled. The transition is not a system transition.

    • Reminder: When the validity of the model should be rechecked, reminders are sent to the responsible user(s).

      note

      When a transition is configured as a Reminder system transition, the Reminder tab will be enabled, allowing you to further configure the reminder details.

    • Accept: When the "Valid from" date has been reached, the state of the model changes to "Valid".

    • Invalidate: When the "Valid until" date has been reached, the state of the model changes to "Invalid".

    • Vote: Activate this setting if the transition represents a vote.

      note

      When a transition is configured as a Vote system transition, the Voting tab will be enabled, allowing you to further configure the voting process.

    • Prolongate: Activate this setting if the transition represents a prolongation action (= extend validity period).

      note

      When a transition is configured as a Prolongate system transition, you can define various actions which are otherwise not available.

The system transitions Reminder, Accept and Invalidate are executed automatically without user interaction. Each night at 1:00 AM local time the ADONIS application server checks whether models meet the specified conditions. If yes, the system transition is executed.

Conditions

The Conditions tab contains the following settings:

RWF Roles Which Are Allowed to Execute this Transition

  • Define the system roles which are allowed to execute this transition.
note

You can only select from the system roles configured for the release workflow on the Configure Roles page.

Model Type Selection

  • Define for which model types this transition is enabled.
note

You can only select from the model types made available for the model release workflow in the Model Type Selection area on the Configure Mapping page.

Process Responsibles Who Are Allowed to Execute the Transition

  • In this area you can specify that only process responsibles can execute this transition. The user must also have the appropriate system role.
note

You can combine multiple conditions. The transition can only be executed if all conditions are met (logical AND operator).

Checks

The Checks tab contains the following settings:

  • Select the Do not execute any check action check box to skip all checks, or clear it so you can define various checks to be carried out before the transition is executed.

  • Select the Do not allow empty models check box to require the model to contain at least one object before the transition can be executed, or clear it to allow transitions with empty models.

Process Responsible

  • In this area you can specify that only models with a process responsible defined in their Notebooks can transition to the target state. You can further specify whether a process responsible has to be user based (a referenced User object), role based (a referenced Role object) or can be both.

  • If Warn if assigned roles are available for reader assignment is activated, ADONIS displays a warning when the transition is executed, and the following condition is fulfilled: A Role object that is used in the model release workflow as a process responsible is Available for reader assignment (object attribute in the Notebook chapter "General information"). The user cannot execute the transition.

Incoming References

  • If Do not allow incoming references is activated, a dialogue will appear when the transition is executed and the model contains incoming references. The transition cannot be executed by the user.

  • If Inform if incoming references exist is activated, a dialogue will appear when the transition is executed and the model contains incoming references. The transition can be executed regardless by the user or aborted.

Outgoing References

  • If Warn if subordinated models are not released is activated, a warning appears when the transition is executed, and the following condition is fulfilled: The model contains at least one Subprocess that references a Business Process Diagram which is not released. The transition can be executed regardless by the user or aborted.

  • Select Include referenced models so that referenced models will also transition to the target state. This is e.g. the case when a model is referenced in a Business Process Diagram as a subprocess.

    If this option is activated, you have to select a strategy for handling referenced models in case of conflict. Include all or none means that transition will only be executed if all referenced models have the correct state for the transition. Include with best effort means any referenced models that cannot be transitioned will be skipped and the transition will be allowed for the rest of the models. User decides lets the user decide between the following options: Do not include referenced models, Include all or none or Include with best effort.

  • If Do not allow if validity period is invalid is activated, the transition cannot be executed if the end of the validity period is in the past.

  • If Do not allow if there is no access to the target model group is activated, the transition can only be executed if the user has write access to the group where the model will appear after the transition.

  • If show success message for checks is activated, a message box will appear when all checks have been performed successfully.

Checks

  • In the Checks area, you can configure which checks are carried out when models are submitted to review. In addition, you can define the behaviour when the check shows that the models are not valid: either the transition may not be executed at all (Block transition), or merely a notification appears (Confirm transition).

Actions

The Actions tab contains the following settings:

  • Select the Do not execute any execute action check box to skip all actions, or clear it so you can define various actions to be carried out after the transition is executed.

  • You can define whether the minor version or major version of the model are increased after the transition is executed.

History Settings

  • Specify whether the user needs to create a comment when they execute the transition. This comment is stored in the Version history of the model (attribute in the Notebook chapter "Lifecycle"):

    • No history entry means that no entry in the version history will be created.

    • Optional comment by user means that the transition will be executed regardless of whether the user enters a comment or not.

    • Mandatory comment by user means that transition will only be executed if the user enters a comment.

    • Create history entry automatically means that a comment is created and stored automatically in the version history of the model. Define the content of the history entry via a support dialogue by clicking the History settings... button.

note

The history settings only have an impact when the Version history functionality has been turned on and configured on the Configure Mapping page. Otherwise, comments cannot be stored in the Version history of the model.

Assign Process Responsible

  • To automatically assign the user who executes this transition as a process responsible, select the Assign current user as process responsible check box, and then select the appropriate attribute.

    Example

    When the default configuration of the model release workflow is in use, the current user is automatically assigned as the “Process analyst/designer” when they create a process (Initial Transition).

note

The setting Assign Process Responsible is only available when a transition is configured as an initial transition on the General Settings tab.

Select Referenced Transitions (e.g. for Archiving Models in the Background)

  • Select referenced transitions for the model or its predecessor model. This is useful to e.g. archive the predecessor version of the model in the background.

New Version

  • Select whether a new version of the model is created. This copy of the original model can e.g. be adapted and released later with an increased version number.

Validity Dates and Prolongation

  • Select the Set validity dates check box to set the validity period when the transition is executed:

    • The model is valid immediately ("Valid from" date).

    • Select the Override existing validity start date with current date check box to explicitly set a released model valid when this transition is executed. This allows your users to change the state of a model that is otherwise stuck in the "Released" state waiting for a scheduled "Valid from" date to arrive. By default, this option is only activated for the special transition Set valid.

    • Select the Set validity date to the end of the month check box to specify that the validity period always ends on the last day of a month.

    • By default, a model remains valid for 12 months after release ("Valid until" date). You can adapt this setting in the Duration of validity period (months) box.

    • The "Resubmission date" (model attribute in the Notebook chapter Lifecycle) indicates to the responsible user(s) when the validity of the model should be rechecked. In the Resubmission date (months before validity end date) box, select how many months before the end of the validity period this date is reached.

    The validity period does not affect the model release workflow as long as the prolongation scenario is not active. For example, no automatic reminders are sent before a model becomes invalid etc.

  • Select the Prolongate check box to prolongate the validity when the transition is executed:

    • The validity period is increased by 12 months by default ("Valid until" date). You can adapt this setting in the Duration of validity period (months) box.
note

The last two options in this area, Prolongate and Duration of validity period (months), are only available when a transition has been configured as a Prolongate system transition on the General Settings tab.

  • Select whether incoming references from the predecessor model are transferred to the new version of the model.

  • Select whether to break outgoing relations of the target model. This function is important e.g. when archiving models. Taking the perspective of another model you can ensure that it will contain no incoming references from an archived model.

  • If Reset validation ToDos is activated, all ToDos are reverted to incomplete when the transition is executed.

  • If show success message for transition is activated, a message box will appear when all actions have been performed successfully.

Notifications

note

The Notifications tab is NOT available when a transition is configured as an initial transition on the General Settings tab.

The Notifications tab contains the following settings:

Send Tasks

  • Define whether ADONIS automatically sends out tasks after the transition. Tasks can be sent to notify the process responsibles and RWF roles which are responsible for executing the next transition in the release process.

Send Emails

  • Define whether ADONIS automatically sends out emails after the transition (To, CC or BCC). Select one or more of the following options:

    • Send emails to notify the process responsibles.

      note

      Process responsibles may be user based (a referenced User object) or role based (a referenced Role object). If the responsibility is defined via a Role, emails are sent to all users with that Role.

    • Send emails to notify the RWF roles which are responsible for executing the next transition in the release process.

    • Define that emails are sent ad hoc and thus allow the user in the web client to select the recipients themselves.

    • Send emails to a predefined user list which you can prepare via a support dialogue by clicking the Add button.

    • Send emails to specific recipients. Enter the email addresses of the recipients in the Send to, Include as CC and Include as BCC boxes. Separate multiple entries with a semicolon.

Send Emails Configuration

  • You can define the content of the email via a support dialogue by clicking the Email text... and Email subject... buttons. Otherwise a preconfigured email is sent.

  • Use plain text or HTML code with inline CSS.

  • You can use the following placeholders that will be replaced by actual data when the email is sent out:

    • %VERSIONHISTORY%: The attribute Version history.

    • %MODELNAME%: The name of the model.

    • %STATE%: The state of the model.

    • %URL%: The URL for opening the model.

    • %SENDER%: The name of the user who executed the transition.

    • %NAME%: The first name of the email recipient.

    • %LASTNAME%: The last name of the email recipient.

    • %VALID_FROM%: The attribute Valid from.

    • %VALID_UNTIL%: The attribute Valid until.

    • %RESUBMISSION_DATE%: The attribute Resubmission date.

note

Before it is possible to send email notifications, the mail settings and the Base URL have to be configured correctly in the Administration Toolkit. For details please refer to the sections Mail and System in the Administration Help (Rich Client).

note

Tasks and emails can only be sent to process responsibles automatically if the process responsible functionality has been activated on the Configure Mapping page.

note

ADONIS will not send out tasks or emails to members of the system role Administrator. This is to avoid spamming these users. Administrators do not have a predefined area of responsibility in the release process. They are responsible for the maintenance of the release process.

Reminder

note

The Reminder tab is ONLY available when a transition has been configured as a Reminder system transition on the General Settings tab.

The Reminder tab contains the following settings:

  • Select the Send Reminder check box to send a reminder to the responsible user(s) when the validity of the model should be rechecked:

    • In the Reference date box, select whether the reminder shall be sent "On Resubmission", before the "Valid until" date, after the "Valid until" date or after the "State change".

    • In the Months/Days area, choose how many Months or Days before/after the Reference date the reminder is sent. For example, if "After State change" is selected as the Reference date and 7 days as the interval, the reminder will be sent 7 days after the model has changed state. This option is not available when the reminder is sent "On Resubmission".

    • From the Interval list, select the interval in which reminders are sent.

    • In the Occurrence box, choose how many reminders are sent.

Voting

note

The Voting tab is ONLY available when a transition has been configured as a Vote system transition on the General Settings tab.

The Voting tab contains the following settings:

  • Select the Active check box to initiate a voting process on the model before the transition is executed. All other options in the Voting area are inactive unless you select this check box.

  • From the Responsible which represents voters list, select who the responsible persons are that may vote. All Users or Roles which are referenced in the Notebook of the model in the selected relation can cast their votes.

    info

    Only one role owner can vote per Role.

  • Click the Define voting question button to define which text is displayed when voters are asked to vote on a model. Enter a text for every language ADONIS supports. Otherwise ADONIS displays a preconfigured text.

  • To specify that users need to create a comment when they vote with Yes or No, select the Active mandatory comment if user voted with check box, and then select the appropriate check boxes. This comment is stored in the version history of the model (attribute in the Notebook chapter "Lifecycle").

  • In the Define follow up transitions area, select the transitions after the vote.

    • From the Transition in case of negative voting result list, select the transition if the vote fails.

    • From the Transition in case of positive voting result list, select the transition if the vote succeeds.

    • For both of these options, select the Start automatically check box so that the follow up transition is automatically executed after the vote.

      note

      If you deactivate Start automatically, the follow up transition has to be executed manually. In this case, both follow up transitions (...negative voting result and ...positive voting result) will be available.

  • In the Transition available while voting is in progress area, select which transitions may be executed to abort the voting process. These transitions must have the same source state as the voting transition.

  • In the Voting strategy area, you can define when the voting process ends:

    • All votes are received means that all voters need to vote.

    • Threshold is reached means that a minimum percentage of positive votes must be received. The vote also ends when too many voters have voted negative and the vote can no longer be successful. You can specify the minimum percentage in the Threshold (minimum percentage of positive votes) (%) box below.

  • In the Threshold (minimum percentage of positive votes) (%) box, specify the minimum percentage of positive votes needed to make the vote successful. If the option Threshold is reached is selected, the vote will end as soon as the threshold is passed.

Configure Voting

Voting processes may be used in sophisticated release workflow scenarios. Typically, a group of people decide whether a model will be released. When the default configuration of the model release workflow is in use, this feature is disabled.

In ADONIS, a voting process is represented by a transition. After the vote ends, different follow up transitions may be executed depending on whether the voting result was positive or negative (e.g. Reject or Release). You can configure multiple voting processes within the model release workflow.

info

Only one voting process may be configured per target state.

Configuration Variants

Depending on the release workflow configuration in use, different steps are necessary to configure voting. The following variants are possible:

Activate Voting for Release

Are you using the default configuration of the model release workflow? In this case, you can activate a preconfigured voting process on models before they are released. In order to do so:

  1. Open the Configure Transitions page.

  2. Open the transition Vote for release for editing.

  3. Switch to the Actions tab.

  4. In the Voting area, select the Active check box, and then click Save.

  5. Click Save.

The voting process is activated and ready for use. All Users or Roles which are referenced in the Notebook of the model as Process managers can cast their votes.

info

Only one role owner can vote per Role.

Once all votes are received, voting ends. The Process owner can then execute the follow up transition manually (either Reject or Release based on the result).

Configure Voting for any Particular Transition

The following steps are necessary to configure voting for any particular transition:

  1. Map model relation that will represent voters

  2. Create transition - general settings

  3. Create transition - conditions

  4. Create transition - actions

Map Relation that Will Represent Voters

In order to map the relation that will represent voters:

  1. Open the Configure Mapping page.

  2. In the Process responsible functionality area, select the Active check box.

  3. Make sure that the relation which represents voters is defined here. You can either use the Process owner, Process manager or Process analyst/designer attribute or define an additional attribute.

Create Transition — General Settings

In order to create a transition representing the voting process and to configure general settings:

  1. Open the Configure Transitions page.

  2. Click the Add new transition button.

  3. In the Language independent name box, type a name for the transition. This language-independent name uniquely identifies the transition.

  4. In the language specific text boxes, type a name for every language ADONIS supports. These names are visible on the user interface.

  5. Select the Create menu item check box.

  6. In the Configure states area, change both the source state and the target state to the state in which the voting process is started.

    Example

    You want to configure a voting process on released models before they are archived. Change the source state and target state to Released.

  7. In the System transition area, select Vote from the list.

Create Transition — Conditions

In order to configure conditions for the voting process:

  1. Switch to the Conditions tab.

  2. In the RWF roles which are allowed to execute this transition area, define the system roles which are allowed to execute this transition. Voters must have at least one of these system roles.

  3. In the Model type selection area, define for which model types this transition is enabled.

  4. In the Process responsibles who are allowed to execute the transition area, select the Active check box, and then select the relation which represents voters.

Create Transition — Actions

In order to configure actions for the voting process:

  1. Switch to the Actions tab.

  2. In the Voting area, select the Active check box.

  3. From the Responsible which represents voters list, select the relation which represents voters. All Users or Roles which are referenced in the Notebook of the model in the selected relation can cast their votes.

    info

    Only one role owner can vote per Role.

  4. From the Transition in case of negative voting result list, select which transition may be executed if the vote fails.

    Example

    You want to configure a voting process on released models before they are archived. Change the Transition in case of negative voting result to No transition selected (= model remains in the state Released).

  5. From the Transition in case of positive voting result list, select which transition may be executed if the vote succeeds, and then click OK

    Example

    You want to configure a voting process on released models before they are archived. Change the Transition in case of positive voting result to Archive.

  6. Click Save, and then click Save.

The voting process is activated and ready for use.

note

Other settings are optional (you can use the default configuration). For example, you may specify that the follow up transition is started automatically when the vote ends etc.

Configure Assignment of Specific Methodical Reviewers

By default, all users with the system role "Reviewer (methodical)" may perform methodical reviews on all models. The Methodical Reviewer attribute enables a better reviewer responsibility assignment. It allows assigning specific methodical reviewers to models if the model release workflow configuration is adapted accordingly.

The following steps are necessary to configure assignment of specific methodical reviewers:

  1. Adapt Transition "Submit to Methodical Review"

  2. Adapt Transition "Submit to Business Review"

  3. Final steps

note

The procedure described here is only valid if the default configuration of the model release workflow is in use. If you are using another configuration, the required steps depend on the design of the release workflow transitions.

Adapt Transition "Submit to Methodical Review"

In order to adapt the transition "Submit to methodical review":

  1. Open the Configure Transitions page.

  2. Open the transition Submit to methodical review for editing.

  3. Switch to the Checks tab.

  4. In the Process responsible area, select the Methodical reviewer check box , and then click Both.

  5. Switch to the Notifications tab.

  6. In the Send tasks area, do the following:

    • Select the Send tasks to process responsible check box, and then select the Methodical reviewer check box.

    • Clear the Send tasks to RWF roles check box.

  7. In the Send emails area, do the following:

    • Select the Send emails to process responsible check box, and then select the Methodical reviewer check box.

    • Clear the Send emails to RWF roles check box.

  8. Click Save.

Adapt Transition "Submit to Business Review"

In order to adapt the transition "Submit to business review":

  1. Still on the Configure Transitions page, open the transition Submit to business review for editing.

  2. Switch to the Conditions tab.

  3. In the Process responsibles who are allowed to execute the transition area, select the Active check box , and then select the Methodical reviewer check box.

  4. Click Save, and then click Save.

Final Steps

Perform the following final steps:

  • Restart the ADONIS application server.

The assignment of specific methodical reviewers is activated and ready for use.

Configure Prolongation

When the prolongation mechanism is in use, a modeller can set a date from which a model will be valid after it is released. By default a model is valid for one year after it is released. Before the model becomes invalid, a reminder is sent to the responsible user(s). The reviewer can then prolongate the model. If the reviewer requests changes, the modeller may create a new draft version in order to adapt the model. Alternatively, the model may be archived.

note

When the prolongation mechanism is activated, each night at 1:00 AM local time validity of all versioned models is automatically checked on the ADONIS application server. This validity check has two effects:

  • When the "Valid from" date has been reached, the state of versioned models changes to "Valid".

  • When the "Valid until" date has been reached, the state of versioned models changes to "Invalid".

Configuration Variants

Depending on the release workflow configuration in use, different steps are necessary to use the prolongation mechanism. The following variants are possible:

Default Configuration of the Model Release Workflow

In order to use the prolongation mechanism when the default configuration of the model release workflow is in use:

  1. Import the extended release workflow configuration that includes the prolongation mechanism configuration (Import component settings). The respective file ADONIS 16.0 - RWF Standard config (incl. prolongation mechanism).axs can be found in the folder “04 Sample Data\Component Settings“ in the installation package. Overwrite the existing configuration with the content of the import file.

  2. Restart the ADONIS application server.

The prolongation mechanism is activated and ready for use.

Adapted Default Configuration of the Model Release Workflow

Are you using a default configuration which has been adapted (additional states or system roles etc.)? The following steps are necessary in order to use the prolongation mechanism:

  1. Activate prolongation mechanism

  2. Adapt source states of existing transitions

  3. Adapt transition "Release"

  4. Adapt transition "Set valid"

  5. Final steps

Activate Prolongation Mechanism

In order to activate the prolongation mechanism:

  1. Open the Configure Mapping page.

  2. In the Prolongation Configuration area, select the Active check box.

The other settings in this area are optional (you can use the default configuration).

Adapt Source States of Existing Transitions

In order to adapt the source states of the existing transitions:

  1. Open the Configure Transitions page, and then open the transition New draft version for editing.

  2. In the General settings tab, remove the source state Released, and then click Save.

  3. Repeat steps 1 - 2 for the transitions Archive and Archive model (system).

Adapt Transition "Release"

In order to adapt the transition "Release":

  1. Still on the Configure Transitions page, open the transition Release for editing.

  2. Switch to the Actions tab.

  3. In the Transition of model list, change the transition from No transition selected to set valid at validity start point. The target state of the model will automatically change from Released to Valid when the "Valid from" date is reached.

  4. In the Transition of predecessor model list, change the transition from Archive model (system) to No transition selected.

  5. Clear the Transfer references from predecessor model check box, and then click Save.

Adapt Transition "Set Valid"

In order to adapt the transition "Release":

  1. Still on the Configure Transitions page, open the transition Set valid for editing.

  2. In the General settings tab, select the Create menu item check box.

  3. Click Save, and then click Save.

Final Steps

Perform the following final steps:

  • Restart the ADONIS application server.

The prolongation mechanism is activated and ready for use.

Specific Configuration of the Model Release Workflow

If you are using a specific configuration, the required steps to activate the prolongation mechanism depend on the design of the release workflow transitions.

note

A complete description of all configuration possibilities goes beyond the scope of this manual. Please contact your ADONIS consultant. They will help you get a new release workflow configuration that includes the prolongation mechanism.

Configure User Rights for the Model Release Workflow

In this section rights settings for two typical scenarios when using the model release workflow are summarised.

note

All descriptions in this section refer to the default configuration of the model release workflow. If you are using a different configuration, adjust the rights settings analogously to the settings described here.

Global Rights Settings

One set of permissions is applied across the organisation (and its business units). This scenario often applies to smaller and/or centrally managed organisations.

Scenario Description

  • Only Modellers can create new models or new versions of released models.
note

This only applies to model types configured for use in the model release workflow. The use of other model types is not restricted.

  • Modellers have write access to models in the state Draft across all business units.

  • Models which are not in the state Draft are read-only for all users with a release workflow role.

  • Reviewers can review submitted models across all business units.

  • Readers have read access to models across all business units. In the Organisation Portal, Readers only have access to released models.

Procedure for Setting the Necessary Rights

  • The individual business units are represented by model groups.

  • Add users to the appropriate system roles depending on their task in the release process. Readers do not a have a release workflow role.

  • Add users to the following user groups:

    • Assign Modellers to a user group that provides write access to all model groups that contain models in the state Draft. This is necessary for the Modellers to create new working versions.

    • Assign Readers to a user group that only provides read access to all model groups.

Business Unit-Based Rights Settings

Different sets of permissions are assigned depending on the user's area of responsibility and business unit within the organisation. This scenario applies to larger and/or decentrally managed organisations.

Scenario Description

  • Only Modellers can create new models or new versions of released models.
note

This applies to the subset of model types configured for use in the model release workflow. The use of other model types is not restricted.

  • Modellers have write access to models in the state Draft in their business unit only. They do not have write access to models in other business units.
Example

Modeller A can create models in "BU1". He only has read access to models in "BU2" and no access to models in "BU3".

  • Models which are not in the state Draft are read-only for all users.

  • Reviewers can review submitted models across all business units.

  • Readers have read access to models across all business units. In the Organisation Portal, Readers only have access to released models.

  • Some Readers (or groups of readers) may not be allowed to see all released models, but only of certain business units.

Procedure for Setting the Necessary Rights

  • The individual business units are represented by model groups.

  • Add users to the appropriate system roles depending on their task in the release process. Readers do not a have a release workflow role.

  • Add users to the following user groups:

    • Assign Modellers to a user group that provides write access to all model groups that contain models of their business unit in the state Draft. This is necessary for the Modellers to create new working versions.

    • Assign Readers to a user group that only provides read access to all model groups. If necessary, restrict the rights further and do not grant access to specific model groups.

Property Filter

Property filters control the visibility of attributes in (the):

  • Tabular Editor

  • Notebooks

  • Reports

  • Model Comparison

You can define different property filters for different system roles and scenarios.

Open Property Filter Settings

To open the property filter settings:

  1. Go to Component Settings > Property Filter > General.

Add and Configure Property Filter

To add a new property filter:

  1. Click the Add filter button.

  2. In the Language independent name box, type a name for the property filter. This language-independent name uniquely identifies the filter.

  3. Type a name for every language ADONIS supports. These names are visible on the user interface.

  4. In the Order area, select the order of the entries when a user selects a property filter in the web client.

  5. In the System role assignment area, select the system roles to which you want to assign this filter.

  6. In the Scenario assignment area, select the scenarios to which you want to assign this filter.

  7. In the Model types | Classes | Relation classes area, select the attributes which should be visible when a property filter is active. You can also deactivate entire Notebook chapters or even all attributes in a specific Notebook at once.

  8. Click Add filter, and then click Save. The new property filter is added and the component settings are saved.

Optionally you can also:

  • Select an existing configuration as a template for your new property filter. On the General page, in the Property filters area, find the filter you want to use. To the right of the property filter, click More, and then click Copy.
System Role Assignment and Scenario Assignment - Filter Visibility

You can combine system role assignments and scenario assignments. A property filter is only visible if all conditions are met (logical AND operator).

Edit or Delete Property Filter

You can edit property filters to fine-tune them, and delete property filters you no longer need:

  • On the General page, in the Property filters area, find the filter you want. To the right of the property filter, click More, and then click Edit filter or Delete.

Settings per Scenario

In this section, you can configure which property filter should be enabled by default in the ADONIS web client. You have the option to set the default filter for all scenarios ("Global") and to define different default filters for specific scenarios as needed.

  • Standard Filter

    Select which property filter should be enabled by default. If a user does not have access to the selected filter, the first filter on the list is activated, then the second filter and so on.

  • Enable 'Show All' Filter

    Select this check box to make the Show all filter available to all users. When the Show all filter is active, all attributes are visible.

  • Enable 'Hide empty attributes' filter in notebooks in read mode

    Select this check box to make the Hide Empty Attributes filter available to all users. When the Hide Empty Attributes filter is active, no empty attributes are visible in Notebooks in read mode.

note

When you define a filter for a specific scenario, it will override the global filter. Switching to this scenario will always set the scenario-Specific default filter, no matter which filter was active before.

Read & Explore Scenario

The Read & Explore scenario is a read-only scenario in the ADONIS web client where users can view processes and working instructions. You can configure various settings for this scenario. For example, you can choose whether the widgets and dashboards display data based on Roles or Organisational Units. You can also select the default model editor and choose which start model should appear on the Read & Explore scenario start page.

Open Read & Explore Scenario Settings

To open the Read & Explore scenario settings:

  1. Go to Component Settings > Read & Explore Scenario > General.

General Settings

The following settings are available:

  • My Processes Based on

    Select what data to display in the widgets and dashboards of the "Read & Explore" scenario. The processes categorised as "My processes" can be derived either from the assignment of Users to Roles or to Organisational Units.

  • Activate Assignment of Roles by Readers

    This option is only available if My Processes based on is set to Roles. In the web client, in the "Read & Explore" scenario, at the top of the My BPM dashboard, the Roles which are associated with the field of responsibility of the current user are displayed ("My Roles"). Select the check box to allow users to add Roles from other areas of responsibility. The selection of Roles determines what data will be loaded in the widgets of the “Read & Explore” scenario.

    note

    The Roles which are relevant for the "Read & Explore" scenario are Role objects referenced in the Notebook of the User object. They should not be confused with system roles.

  • Set Textual View as Default Editor

    Select this check box to make the textual view the default editor in the "Read & Explore" scenario. All model types with a textual view configuration will be opened in the textual view by default. When you clear this check box, the graphical editor will be the default editor for all model types.

  • Activate State Filter (Show only Released Models and Objects)

    Select this check box to only show models and objects in the state "Released" in the "Read & Explore" scenario. Model and object types without a state set by a release workflow are not affected.

  • Allow Users to Configure Start Model

    Select this check box so that users can set their own start models for the "Read & Explore" start page. For this option to work, Enable start model (see below) must also be activated for the repository.

Select Start Model per Repository

Here you can specify a start model that will appear on the "Read & Explore" scenario start page. You can define a configuration for each repository.

The following settings are available:

  • + Select Repository

    Choose the repository for which a start model should be set up.

  • Enable start model

    Select whether a start model will be displayed.

  • + Select Model

    If Enable start model is activated, you can select the start model here.