Participant Roles

Impact: Participant and Group Roles Overview

Participants roles can be defined when evaluating:

  • the Likelihoods of:
    • threats, 
    • events given threats
    • events with no threats
  • the Impacts of:
    • events with respect to objectives 
    • objectives, and
  • the Effectiveness of
    • Controls

On this page, we will focus on participants' roles for evaluating the Likelihoods. 

This can be found on IMPACT OF EVENTS > STRUCTURE > Participants roles

The Participant Roles page for Impact consists of:

  1. The For Event Consequences/For Priorities tabs to assign roles for evaluating events consequence with respect to objectives and for objectives priorities respectively
  2. The Participants/Groups tabs toggle between the participant's list and the group's list of the model.
  3. The first column of the grid displays the Events list
  4. The grid headings (next to the Events) displays the Hierarchy of Objectives
  5. The intersecting cells were to assign roles for evaluating the event (row) with respect to covering objectives (column)
  6. Toolbar options 

Roles can be set for:

  • The "All  Participants Group" (every participant belongs to "All Participants")
  • Any Defined Participant Groups (non-dynamic and dynamic groups) 
  • Each individual Participant Roles

How Roles are processed -- Three rules: 

  1. A role explicitly assigned for a participant OVERRIDES any role defined for:
    • The 'All Participants' Group
    • Any defined groups to which the participant belongs
  2.  Roles for the 'All Participants' Group and any Defined Groups have the same priority
  3.  A restrict role overrides an Allow role

Roles can be assigned for:

  • Sub-objectives with respect to their parent Objective and
  • Events with respect to covering objectives

Assigning roles without groups is a simpler way of setting up roles. Setting up roles with groups is a very flexible and powerful method, but somewhat more complex.  

Impact: Setting Up Roles without Groups

Roles can be assigned to Participant Groups (custom groups or a pre-defined group called 'All Participants') as well as to individual participants. The resultant role for a participant is a combination of the roles assigned to any group to which the participant belongs (including the pre-defined 'All Participants' group) and any role explicitly assigned to the individual participant. 

In this topic, we will focus on Setting up roles without groups. For the purpose of setting roles without using participant groups, all we need to know now is that a participant will have a role for every node (as defined by the "All Participants" group which by default is Allowed) unless they are explicitly restricted for one or more nodes. 

Since each participant has an implicit allow role for every node, the easiest way to set roles is to restrict nodes for which a participant should not have a role.  (There is no need to explicitly allow roles when participant groups are not being used.)

Roles for Evaluating the Objectives Priorities

Click the "For Objectives Priorities" tab to assign roles for evaluating objectives. Roles for evaluating the objectives are represented by the colored boxes on the non-covering objectives as below:

The headers are arranged according to the objectives hierarchy/leveling. For example, the Objectives is the top-most node and its top-level children are the Public Relations, Financial, and so on...

An 'Allow' role for the top node means that the participant will have the role of evaluating the top-level objectives. The allow role for an objective node means that the participant will have the role for evaluating the sub-objectives with respect to that objective. 

You will notice that all of the cells in the figure above have a background of light green because by default, the "All Participants" group has an 'allow role' for everything, and we have not defined any custom groups that might have had one or more 'restrict' roles.

In addition to the implicit assignment of roles based on participant groups, an explicit role can be specified for a participant (either allow or restrict). If this is the case, there will also be an interior color for the node and the background color will appear as a border.

The 'Financial" node has an explicitly restricted role in the figure above and thus appears as a red interior with a green background or border. Since restrict overrides allow (roles three rules), the participant would not have a role in evaluating the sub-objectives of "Financial" given their parent (Financial).

Roles for Evaluating the Events Consequences

Click the "For Event Consequences" tab to assign roles for evaluating the consequences of events with respect to objectives. Roles for evaluating the events are represented by the boxes on the intersecting cells of the events (row) with respect to the covering objectives (column) -- see below. 

All of the intersecting cells in the figure below have a background of green because by default, the "All Participants" group has an 'allow role' for everything.

In addition to the implicit assignment of roles based on groups, an explicit role can be specified for a participant (either allow or restrict).  If this is the case,  there will also be an interior color for the cell and the background color will appear as a border.  

"Late Train Running" in the figure above that has an explicit restrict role -- and is shown as a red interior with a light green background or border -- when evaluating given the covering objective "Loss of Company Reputation".  

The   yellow interior color on the "Late Train Running" represents that the participant has different explicit roles for evaluating "Late Train Running" with respect to the covering objectives -- from above, one is restricted while others are "undefined" (no interior color). Same reason for the yellow interior color for the "Loss of Company Reputation" cell -- the participant has different explicit roles for evaluating each of the events with respect to "Loss of Company Reputation".

The blank cells mean that the event is not vulnerable to the covering objective. 

Note: If there is a blank cell, this means that the event doesn't contribute to the covering objective. 

How Participant Roles are Assigned?

We can assign roles explicitly while in Edit mode. Edit mode is the mode selected by default.

To assign roles to a participant, simply check the check box to the right of the participant name on the left pane:

You can also select multiple participants at a time for assigning roles using the Shift and Control keys.  

By successively clicking on a cell, the interior color of the cell will change to:

  • dark green (indicating a role that is allowed explicitly)
  • dark red (indicating a role that is restricted explicitly), or
  • light green  (indicating a role that is allowed implicitly, based on participant group roles).

You can set the roles for all events or objectives at once by using the:

  • Allow All (explicit allow)
  • Drop All, or (no explicit specification)
  • Restrict All (explicit restrict)

buttons, and then selectively click other nodes as desired.


For events, you can also define the role for:

(1) one event with respect to all covering objectives; or 

(2) all the events with respect to one covering objective at once, 

by clicking the box on the event or covering objective names.

The yellow interior on the event names (rows) and covering objectives (columns) represents that the participant has different explicit roles for evaluating the event with respect to each of the covering objectives; or that the participant has different explicit roles for evaluating the covering objective given each of the events.

Impact: Setting Up Roles with Groups

Setting up roles with groups is a very flexible and powerful method, but somewhat more complex.

Every participant belongs to a Participant Group called "All Participants".

The All Participants group initially has an "allow" role for all cells as seen below.

You can create additional Participant Groups from the Participants page.

There are three types of roles that can be specified for groups: 

  • Allow  
  • Restricted
  • Undefined  (Neither Allowed or Restricted)

The role of a participant for any node depends on:

  • Roles for the "All Participants" Group
  • Roles for any defined Participant Group to which the participant belongs
  • Roles explicitly assigned for the participant

Similar to Setting up roles without groups, you can also assign roles to groups by clicking on the cells individually, by entire row/column, or by using the Allow/Restrict/Drop all buttons. 

Each Column in the following figures represents a Case Illustrating the Above Rules

Case 1 is the default. The result is Allow.

Case 2 is a simple way to restrict individual roles.

Case 3 is equivalent to case 1.

To use roles with groups, we recommend that you start with No Specifications for the  'All Participants' group.

Cases 4 and 5 are obvious.

Case 6 shows a restricted group specification overrides an allowed group specification (Rule 3).

Case 7 illustrates if no roles are allowed for All Participants and Any Groups, then the Individual's role is Restricted.

Case 8 shows an Individual Participant's role overrides any group roles (Rule 1).

Case 9  An Individual's specification overrides any group specifications (Rule 1).

Cases 10 and 11 show a restricted group specification overrides an allow specification (Rule 3).

Impact: Participant Roles Edit vs View Mode

Edit Mode

The Edit Mode is a mode where the Project Manager can assign roles by clicking on the cells or using the Drop/Allow/Restrict All options. 

Two participants are selected in the example below. The border of the node (in this case light green for all nodes) reflects the roles implicitly assigned to the participants based on the roles assigned to the groups they are in. The interior represents the role, if any, explicitly assigned to the selected participants. 

If they are not the same, yellow is displayed as for Public Relations and Financial see below.  

To better understand what the yellow means, let's look at the roles assigned for objectives for Steve and Kris, one at a time.  

First for Chief Risk Officer:  As we see below, the interior of the nodes "Chief Risk Officer" is a light green, the same as the border,  meaning that neither allow nor restrict was specified for any node for Chief Risk Officer (if a role had been previously specified, it has been 'dropped'). Thus, Chief Risk Officer has a role for every threat and sub-threat based on the roles assigned to groups to which Chief Risk Officer belongs.

Now let's look at Chief Engineering Officer roles:


As can be seen above, the Chief Engineering Officer has been explicitly  assigned a role for Public Relations and explicitly  restricted a role for Financial. The explicit assignment for Human Factor doesn't have any impact since, as can be seen from the border of that node, Chief Engineering Officer would have had that role based on the roles of the groups to which the Chief Engineering Officer belongs.  However, if later, the role for Human Factor for one of the groups to which Chief Engineering Officer belongs is changed to 'restrict', this explicit assignment would override it since an explicit assignment for an individual overrides any group role assignments. If that were the case, then the Chief Engineering Officer node for Human Factor would have looked like this:

Let's now return our attention to the display when we look at the roles with both Chief Risk Officer and Chief Engineering Officer selected on the first image above. 

A node is displayed as yellow  in the Edit Mode if the individual role explicitly assigned to all of the selected participants is not the same. Public Relations is yellow because Chief Engineering Officer has an explicit role assigned for this node, but Chief Risk Officer does not -- so they are not the same. Financial is yellow because Chief Engineering Officer has an explicitly restricted role while Chief Risk Officer has no explicit role -- so again, they are not the same. 

From the example, above we can see that in the Edit mode, we are can only determine whether the individual roles for the selected participants are the same or different, but we can not determine their resulting roles. 

View Mode

As discussed above, the 'Edit mode' is the mode used to assign roles. We can not determine whether the resulting role for all the selected participants is the same or not from this display. The resulting roles can be determined using another mode called 'View mode'.

 You can switch to the View mode using the menu as shown below:

If we look at the display for the same example above for the "View mode", we would see the following:

Since both Chief Risk Officer and Chief Engineering Officer have the same resulting role (allowed) for Public Relations, even though they have different explicit assignments, the node is shown as green.  The Financial node is still yellow because one of the participants has the role and the other does not. We would have to look at each participant individually to see which one has that role and which one does not.

Examining roles for all participants in the View mode

It is advisable to select all participants in the 'View' mode to see if there are any nodes that are red, meaning that no participant has been assigned the role for that node.

Impact: Copy and Paste Roles

You can copy roles from one participant to another:

  1. Select the participant you want roles to be copied
  2. Click Copy Roles
  3. Select the participant(s) where you want to paste the roles 
  4. Click Paste Roles

You can also select multiple participants to whom you want the roles to be copied.

Impact: Participant Roles Statistics

You can view the number of participants that have an allowed role by checking the Show Statistics check box. 

Recommended Approaches for Setting Roles for the 'All Participants' Group

Assigning roles to participants can be without using groups as well as with groups.  In the former case, we advised leaving all roles allowed for the All Participants Group as they are set by default.  In the case of assigning roles using groups, we advised starting by dropping all roles for the All Participants Group.  There is one additional contingency to take into consideration:  If new participants are added to the model after roles have been assigned to existing participants, what do we want the roles for the new participants to be?  We describe three cases:

Case 1) If you want the roles for 'new' participants to be 'allowed' for everything, then leave the 'All Participants' group roles set to 'Allow' as they are by default.

Case 2) If you want the roles for  'new' participants to be 'allowed' for almost everything, then leave the 'All Participants' group roles set to 'Allow' as they are by default and 'restrict' roles for the new individuals as desired or add them to groups that have roles restricted for the desired nodes.  (The latter can be done via a survey containing a question that is used to assign new participants to a group).

Case 3) If you want the roles for  'new' participants to be 'restricted' unless the new participant is in a group or groups that have specific roles enabled, or only if you explicitly allow roles for the participant, then 'Drop All' roles from the 'All Participants' group.