OMM - Organizational model manager

Introduction

This manual describes the organizational model used by Q-flow and the tool that allows you to modify it.

Manual organization

This manual has two parts. The first part explains the organizational model used by Q-flow and the concepts that this model uses. It includes a section about permissions handling in Q-flow.

The second part explains the way in which the organizational model manager works. It is the tool that allows you to modify the organizational model.

Organizational model

This section describes the organizational model, the elements that comprise it and some concepts that are necessary to understand it.

Organizational model elements

Q-flow’s organizational model handles three types of elements:

Nodes
Groups
Users

Nodes

Nodes are used to organize the organizational model’s structure in a hierarchical way. There is a node that is the structure’s root. A node can contain groups and users, as well as other nodes. A node is a container of other elements, and a set of nodes form a tree structure similar to the folder structure that is used to organize a computer’s files. The organizational model manager shows that tree structure.

Just like folders, nodes have names that allow you to identify them. Additionally, nodes have security properties that allow you to define who can see or modify them and the ways in which they can do it.

Nodes can behave like work queues. Work queues can be selected as task addressees. When a task is assigned to a node that behaves as a work queue, any user that has permission to respond to tasks in that queue can respond to the task.

Groups

Groups allow you to group users who share certain properties. In addition to containing users, a group can contain other groups. They are normally used, for example, to group users who perform the same function, without it being reflected in the organization’s structure: a user can belong to several groups, but only belongs to one node, which represents the department or division to which the user belongs.

Users

Users represent Q-flow users. A user can be a member of several groups, but cannot be in more than one node. Users and their data can be imported from a directory service such as Active Directory.

Permissions handling in Q-flow

Almost all the tools that comprise Q-flow allow you to define access permissions of some kind. For example, all the customer tools (organizational model manager, business process web designer, business process manager, web site, system administration and monitoring) allow you to define who can access them. This section explains the security mechanisms that are common to all of the tools.

Inheritance

Q-flow handles the concept of permissions inheritance. This concept is known by those who assign permissions to folders in Windows. In Window’s file system, when someone defines a permission for a folder, that permission is inherited by that folder’s subfolders. Windows’ file system structure is a tree structure: each element of the structure has a parent, except for the root.

Q-flow has two tree structures with elements in which permissions can be defined:

Organizational nodes tree: it is the tree that represents the organization’s structure and it contains nodes, groups and users. The tool that allows you to modify the tree and determine who has permission to access its elements is the organizational model manager.
Packages tree: it is the structure that allows you to organize the elements that represent Q-flow’s processes. The tool that allows you to modify this tree is the business process designer. In it, permissions to access those elements are handled from the perspective of process designing. The same structure is used to organize the processes being executed, and in Q-flow’s website, permissions for that structure’s elements are handled from the perspective of processes’ execution.

Both structures’ elements can inherit permissions, but this is optional and is defined for each node or package. For example, if a user is assigned an inheritable permission to see the root node’s items, that user will be able to see the items of the root node and all its descendants, i.e. all the tree’s nodes. In the same way, if an inheritable permission for the root package is assigned to them, the user will have permissions for all of Q-flow’s packages.

It is important to take into account that the concept of inheritance always refers to objects for which permissions are defined, such as packages or nodes in Q-flow and folders in Windows. There are other hierarchical structures in Q-flow apart from nodes and packages trees. An example is the structure defined by group membership relations. This is not different from Windows, where a group can contain users and also other groups, thus forming a tree. The difference is that while nodes and packages are the objects for which permissions are defined, users and groups are the subjects to whom permissions are given. A permission gives someone (subject) access to something (object). Every time we refer to the concept of inheritance we refer to objects and not subjects.

Types of Q-flow permissions

There are three types of Q-flow permissions:

Permissions to access a tool: they are permissions related to the access to a tool (business process designer, organizational model manager, business process manager, system administration and monitoring and web site). These permissions are defined independently for each of Q-flow’s tools. In general, the tools have two permissions: “Access tool” and “Manage security”, as well as others specific to each of them. The objects of those permissions are the tools themselves, which are not part of any hierarchical structure, so inheritance makes no sense in this case. Permissions for accessing a tool are modified in the tool itself.
Node permissions: they are the permissions related to operations on organizational nodes. For each of these permissions, whether they are inheritable or not can be specified. Some nodes can also be work queues. This is why there are two types of permissions for a node:
- Permissions for a node in its organizational element role: they are the permissions that are defined in the “Security” group of a node’s properties form in the organizational model manager.
- Permissions for a node in its work queue role: in Q-flow, it is possible to determine that a node should also be a work queue. In that case, the permissions that determine which users can respond to tasks from that work queue must be defined. These permissions are defined in the “Security” group of a work queue’s properties form.
Packages permissions: they are permissions related to operations on packages. For each of these permissions, whether they are inheritable or not can be specified. There are two types of permissions for packages:
- Permissions for a package in its process definition container role: they are defined in the business process designer. These are related to operations that allow you to define processes and see the representations of the defined processes. Check the Business Process Designer manual for more information.
- Permissions for a package in its executing process container role: they are defined in the web site and are related to operations related to the processes’ operation. Check the Web site manual for more information.

Permissions subjects: users, groups, nodes and security roles

A permission can be assigned to a user, a group, a node or a security role. Security roles are associated to nodes, groups and users, and are used to group permissions and organize them to simplify their administration. Cases in which several permissions are assigned all together to many users who perform the same role are common. For example, a “Security manager” role that has permission to manage the security of all of Q-flow’s tools could exist. In that case, a security role named “Security manager” could be created and be assigned, in each tool, the tool access and tool security management permissions. Afterwards, that security role could be associated to the corresponding users, or a group that contains those users. This permissions organization system is called RBSA (Role Based Security Administration).

Since a user can be associated to several security roles and belong to many groups, sometimes it can be complicated to determine which permissions a user effectively has. This is why it is useful to have good knowledge of the rules that determine how a permission that is assigned to an element affects the elements that are related to it.

A permission that is conceded to a user affects only that user.
A permission that is conceded to a group affects all the users that belong to that group and all the nodes and groups that belong to that group.
A permission that is conceded to a node affects all the users, groups and nodes that belong to that node.
A permission that is conceded to a security role affects all the users, nodes and groups that are associated to that security role. The security role’s permissions affect elements associated to that role in the same way that each of the permissions would affect them if they were assigned in an independent way. For example, if a permission is conferred to a security role and there is a group associated to that security tole, all users, nodes and groups that belong to that group will have the permissions specified in the security role.

Security roles must not be confused with process roles, which are a way of abstracting a process’ tasks from the users that perform them and that are defined in the business process designer.

Conflicts between permissions

Aside from giving someone permission to perform an operation, this permission can be explicitly denied. A user can belong to more than one group. It may happen, therefore, that there are contradictions between the permissions of one group and the other.

Given a user and a permission, there are four possibilities:

The permission is not defined for the user.
There is at least one definition that confers the permission to the user and none that denies it.
There is at least one definition that denies the permission to the user.
There is at least one definition that confers the permission to the user and at least one that denies it.

The only case in which the user will effectively have the permission is the second one. To summarize, for a user to have permission to perform an operation, there must be at least one definition that concedes that permission to them and there cannot be any definitions that deny it to them.

The deny permissions option has two common uses:

Excluding an organizational element from a permission given to an organizational element that includes it (for example, if a user belongs to a group that has permission for something and you wish to deny that permission to the user without removing them from the group).
Avoiding inheritance in a branch of the nodes or packages tree (for example, a user has a certain permission for the root node, but you wish to prevent them from having said permission for a certain node).

Other important concepts

The following are other concepts that should be taken into account to take advantage of the organizational model’s features.

Managers

The manager role is a special role that can be performed by a user or a group and that allows you to establish hierarchical relationships inside the organizational model. Managers can be chosen as addressees for alerts of flows that are waiting for their subordinates’ actions.

Substitutions

Q-flow allows you to define substitutions. A person can take a leave of absence from the organization (for example, because they are sick or on holiday). While they are not there, it is likely that they will still be assigned tasks, or that they will continue to receive notifications, according to the functions they perform. To prevent those tasks from being left unfinished, or delayed too long, making notifications go unanswered, it is possible to assign a substitute to the person for the duration of their absence.

Q-flow will automatically handle the task of sending all the notifications that the absent person is receiving to the substitute. They will also have access to the tasks of the user who they are substituting, with enough permissions to be able to perform them in their place (but no more than those permissions).

A user can be substituted even when they are disabled in Q-flow and even then, their substitute will have the permissions that allow them to perform the tasks of the user who they are substituting.

Organizational model manager

The Organizational Model Manager is the tool that allows you to modify and maintain Q-flow’s organizational model.

Accessing the web site

To access the web site it is necessary to open an Internet browser and enter the organizational model’s address, whose default URL is http://<<server>>/QflowOMMWeb where <<server>> must be replaced by the name of the Q-flow server.

The system supports three user authentication models: integrated security, user and password or authentication with Google or Microsoft accounts. If it is configured for integrated security, the system will recognize the user registered in Windows and will attempt to use those credentials to access the organizational model manager.

In the case that the user does not have permissions or the system does not recognize them, the authentication form will be presented as shown in Fig. 566.

The screen shows the following options:

Username: the name of the user with which you wish to log in.
Password: the password with which you wish to log in.
Security provider: the security provider that authenticates the user (for example, the company’s domain).
Login with Microsoft account: selecting this option will take you to a view where the user’s Microsoft credentials will be requested to authenticate the account.
Login with Google account: selecting this option will take you to a view where the user’s Google credentials will be requested to authenticate the account.

General user interface description

The interface’s main elements are:

Main screen: it allows you to visualize the currently enabled users, their history and the 10 most recent logins.
Upper menu: it presents options to search for elements, access the settings screen, go to the home, configure your preferred time zone and log out.
Side menu: it allows you to show/hide the solution tree (by default Root) and operate on the tree’s organizational nodes.
Organizational nodes tree: it allows you to see the organizational model’s hierarchical structure and to select the element on which you wish to operate.

Fig. 567 Organizational model manager main screen

Upper menu

Fig. 568 shows the upper menu options and describes the function they perform.

The options that require clarification are explained next:

Quick search: it allows you to search for a user, group or node. When an element is sought, Q-flow will show a list with all the found elements that contain the entered text. In the case of users, both their name and login will be searched.
Settings: when this option is selected, the system displays a set of options like Fig. 569 shows. More details in Settings.

Information: when this option is selected, the system displays links to the product news and this manual, as well as being able to see the version of the product that you are using.

When you open the “Current user” option, the system displays the user’s preferred time zone. This time zone is used in all of Q-flow’s dates and times for the current user. The preference is shared with all the product tools, so modifying it in one of them will affect the others.

To edit the time zone, the “Current user” option in the menu must be selected. This will open a right panel with the list of available time zones. Once the time zone has been selected, when the panel is saved, the page will automatically refresh so that the change takes effect. If more windows are open with Q-flow’s tools in them, they must be manually refreshed for the change to take effect.

Main screen

When a user enters the organizational model manager, or clicks the tool’s icon in the upper left section, Q-flow shows them the main page.

The main page has the following elements:

Enabled users indicator: it allows you to view the number of users that are currently enabled, as well as comparing it to the number of users that the current license allows.
Enabled users history: it allows you to view the number of enabled users in the last 12 months.
Recent sessions: it allows you to view the 10 most recent logins, considering all of Q-flow’s tools.

Difference in versions

Unlike the product’s Cloud version, the OnPremise version does not have the “History of enabled users” chart.

Organizational nodes tree

A node can be shown open (its children are shown) or closed (they are not shown). To open a node, click the triangle to its left, which indicates if it is open or closed. For example, in Fig. 574 the Root and Operations nodes are open while the Administration node is closed. You can see that the Operations node contains two others: Maintenance and Production.

It is also possible to move nodes by dragging them from their original place to the new destination. To do this, click the node you wish to move, drag it to the destination and let go of the mouse button.

If you double click a tree node, a list will open in the main panel with the users and groups that belong to the node selected in the tree (Fig. 575).

In the upper left section there is a tool bar. Fig. 576 shows said bar’s elements and their purpose is later described.

New user: it creates a new user. When the user clicks this icon, a panel is shown that allows you to enter the user’s name, a description and their main data, such as e-mail and login. More details in User properties.
New group: it creates a new group. When the user clicks this icon, Q-flow shows a panel that allows you to enter the group’s name and a description. More details in Group properties.

Fig. 578 Toolbar - Edit/Cut/Paste/Delete

Edit: when the user clicks this icon, a panel is shown that allows you to edit the selected user or group’s data. Another way to access this option is to select the element you wish to edit and then double click it.
Cut and paste: these options allow you to cut the selected user or group from a node to then paste it in another node. In other words, they allow you to move the selected user or group. This is the only way to do this, since dragging users or groups from a node to another is not allowed.
Delete: when the user clicks this icon, a warning sign is shown and if you click the Ok button, the selected user or group is deleted.

Fig. 579 Toolbar - History/References/Permission tracking

History: it shows a panel that lists the modifications made to the selected element (node, user or group), as well as the dates on which they were made and the name of the user who made them (Fig. 580). The time zone of the shown dates is also indicated.

References: it shows the elements related to the selected object, including process template roles, security roles, nodes, groups and security definitions. For example, if a user has permissions for Q-flow’s model manager, when viewing that user’s references, those permissions will appear (Fig. 581). The user references that you can view are: package log, flow log, flows, attachments, flow roles, flow steps, timed actions, flow stages, groups, managed, substituted, permissions, packages, template roles, links and node log.

Permission tracking: this option is only available for users. It shows a panel (Fig. 582) in which all the user’s effective permissions regarding nodes appear. Effective permissions are all the permissions that the user has, that is, not only the ones that were directly given to them, but also the ones that were indirectly given, through a group, node or security role. The panel has an option to only show the permissions that the user has for work queues.

Fig. 583 Toolbar - Send notifications/Import data from directory

Send notifications: it allows you to forward the messages corresponding to the user’s active tasks to them, within a certain period.
Import data from directory: it allows you to load the user’s data with data imported from a directory (for example, Active Directory). More details in Importing a user’s data from a directory.

Fig. 584 Toolbar - Disable/Enable members

Disable/Enable members: this option allows you to enable or disable users and groups. Remember that each enabled user uses part of the Q-flow license.

In the upper right section there is also a toolbar. Fig. 585 shows said bar’s elements and describes their purpose.

The operations mentioned in the image are described next:

Search members: it allows you to type a short text and filters the users and groups according to it, showing only those whose names contain it.
Refresh: it reloads the users and groups, making the list show modifications made in other devices after the last time it was loaded.
Rows/Columns: it allows you to modify the way in which Q-flow shows users and groups in the panel.
- Rows: it is the default option, as you can see in Fig. 575. It shows the groups and users as a list of large icons. Aside from each user or group’s name, it shows their e-mail.
- Columns: it shows users and groups as a list of small icons. Additionally, it shows each user and group’s e-mail, description (optional) and their status (enabled or disabled).
Columns: this option allows you to choose whether you wish to show each user and group’s description in the previously detailed column type viewing or not.
Show users: it shows or hides users. If the button is activated as in Fig. 585, it shows them. Otherwise, it hides them.
Show groups: it shows or hides groups. If the button is activated as in Fig. 585, it shows them. Otherwise, it hides them.
Show disabled users and groups: if this button is activated, Q-flow shows disabled users and groups in the main panel. Otherwise, it does not.

Context menus

The Organizational Model Manager allows you to perform some of the operations available in toolbars through context menus. To open a context menu, right-click the element on which you wish to perform the operation. For instance, to create a node in the tree, click the node in which you wish the new node to be contained. If you select several elements and right-click the selection, Q-flow will also show the context menu, but in this case the menu will not have options that correspond to operations that cannot be performed simultaneously on many elements. Fig. 586 shows the tree’s context menu. Fig. 587 shows users’ and groups’ context menus.

Node tree's context menu — Fig. 586 Node tree’s context menu

Users' context menu (left) and groups' context menu (right) — Fig. 587 Users’ context menu (left) and groups’ context menu (right)

Context menu operations that were not previously explained in the toolbar from the Organizational nodes tree section will now be described.

Member list: it shows the users and groups contained in the node that was clicked.
New organization node: it creates a new organization node inside the node that was clicked.
Rename: it allows you to change the selected node’s name without needing to open its properties form. This option is similar to the one that allows you to rename a file or directory in Windows. When you select it, the element’s name is selected and a cursor appears that allows you to modify the text.
Delete: it deletes the selected object.
Refresh: it updates the tree’s structure, from the selected node downwards.
Import node from file: it imports a node (that is, the entire branch defined by a node) that was exported in some other environment and places it inside the selected node. When elements whose identifiers coincide with existing elements are imported, the latter are updated with the imported data, but if they were in another node, they are moved to the selected node. More details in Import node from file.
Export node to file: it exports the branch defined by the selected node to a file. This file can later be used to import the exported branch in another environment in which Q-flow is installed. Aside from the selected node and its content (descendant nodes, users, groups) all of the system’s security providers, calendars and roles are exported. More details in Export node to file.
Import users from directory: it allows you to import users from a directory, such as Active Directory, in a node. More details in Import users from directory.
Properties: it shows the selected node’s properties panel.

LDAP path specification

Nodes, users and groups have a property in which an LDAP path can be specified to synchronize its data with a service directory’s. The property is in the “Advanced” group of a node, group or user’s properties panel.

“Advanced” group from a user's properties form — Fig. 588 “Advanced” group from a user’s properties form

To select the path:

Click “Select”. This makes Q-flow show a panel like the one in Fig. 589, in which the directory element corresponding to the node, user or group can be selected.

Select the domain you desire in the list that appears to the left of the “Load” button and click said button. This will load the list that appears in the panel’s lower half (Fig. 590). It shows the directory’s organizational units and allows you to select some of them, or a group. To see a group, open the organizational unit to which it belongs (Fig. 591).

Fig. 590 Directory explorer with loaded nodes

Fig. 591 Open organizational unit with all its groups

Select from the list the element that you wish to associate to the node, user or group that you are modifying and click “Save”. You can select a directory node or group.
If you are specifying an LDAP path for a user, the procedure is the same, except there is an additional table that shows all the users of the selected element (Fig. 592). If there are many users in that element, you can filter the users list by using the quick search that appears over the list. If you have created a user and import its data, the user’s name will change and become the imported name.

Fig. 592 Directory data importer with loaded users

Node properties

To modify a node’s properties, search for it in the organization nodes tree, right-click it and select the context menu’s “Properties” option. Q-flow will show the panel that appears in Fig. 593.

The form divides a node’s properties into the following groups:

General: it shows and allows you to modify the name, description and enabled or disabled status.
Properties: it shows and allows you to modify the node’s additional properties. Additional properties are not defined in Q-flow, but are properties that the organization defines to complement the ones that come with the product.
Roles: it allows you to add and remove security roles, thus associating them to the node.
Managers: it shows the list of users and groups that act as the node’s managers and allows you to modify the list.
Advanced: it shows and allows you to modify the work queue behavior and directory synchronization.
Security: it allows you to specify which users, groups and security roles have permissions for the node and what those permissions are.

The “General” group is the only one shown by default. For the groups described later on to appear, display them by clicking the “+” button.

General

They are the same properties that can be modified when creating the node.

Name: it is the name that appears next to the node in the tree. In Fig. 593, the name is “Administration”.
Description: a brief description of the node.
Enabled: it allows you to enable or disable the node. If a node is not enabled, it appears gray-colored in the tree.

Properties

The “Properties” group shows the node’s additional properties. For more information on additional properties, go to the Additional properties section.

Roles

The “Roles” group (see Fig. 594) allows you to define the node’s security roles. Users and groups’ properties forms also have this group, which works in the same way as in nodes.

To add a role to the node, write part of the name of the addressee who you want to add as a role where it says “Start typing…”, and when you see it in the list that Q-flow shows, select it.

To delete a role from the node, simply click the “x” symbol that appears next to the role.

Note that this does not delete the role. It only removes it from the roles list of the node that is being modified.