System Actions at the Group Organization Unit and Position Level

To be able to create a supervised work view in the application, and to use some of the functionality available from the supervised work view, you must have the appropriate scoped system actions, that is, system actions configured on an individual group, organization unit, or position.

System actions at the group, organization unit, and position level are defined in TIBCO Business Studio by selecting the group, organization unit, or position, then associating a privilege with the appropriate scoped system action:

Note that although there are seven scoped system actions available in TIBCO Business Studio, there are only three of them that are used in Workspace at this time. Those are:

  • BRM.viewWorkList - Controls access to supervised work views:
    • To create a supervised work view for an organizational entity, you must possess the privilege assigned to the system action, BRM.viewWorkList, on the group, organization unit, or position.
    • To create a supervised work view for an individual resource, you must possess the privilege assigned to the system action, BRM.viewWorkList, on a specific position to which the resource has been mapped

      This is further explained in Creating Supervised Work Views.

  • BRM.closeOtherResourcesItems - Controls whether you can cancel a work item in a supervised work view for another resource.
  • BRM.reallocateToOfferSet - Controls whether you can allocate a work item to a specific person in the original offer set.

The scoped system actions available in TIBCO Business Studio that are not currently used in the application are:

  • BRM.setResourceOrderFilterCriteria (Eventually this may control whether someone viewing a supervised work view can save filter and sort criteria to the server so that it will become the default for that resource.)
  • BRM.openOtherResourcesItems (You cannot open another resource’s work items from a supervised work view.)
  • BRM.reallocateWorkItemToWorld (This system action is available at the organization model level; use that one to also control access to the Allocate Work Items to World function on a supervised work view for a resource; this function is not available on a supervised work view for an organizational entity.)
  • BRM.workItemAllocation (This system action is available at the organization model level; use that one to also control access to the Allocate functions on a supervised work view.)

Creating Supervised Work Views

The primary use of the scoped system actions are for controlling the ability to create supervised work views. A few of the other system actions available at the organizational entity level control access to functions from a supervised work view. But those, of course, would have no meaning unless you can first create the supervised work view.

The following describes what is necessary to set up system actions to be able to create a supervised work view.

When a supervised work view is created in the application, it can be set up to contain either:

  • Work items sent to an organizational entity - This type of supervised work view only contains work items that were sent directly to the specified organizational entity. When creating this type of supervised work view you can specify that the view contain either work items that were offered to the organizational entity and that still have a state of Offered, or work items that were offered to the organizational entity but that are now allocated to one or more users (i.e., their state is Allocated).

    To be able to create this type of supervised work view:

    • A privilege must be assigned to the BRM.viewWorkList system action for the group, organization unit, or position for which you want to supervise, and
    • you must possess the privilege (and possible qualifier) assigned to the scoped BRM.viewWorkList system action for the organizational entity you want to supervise (you gain the privilege by being mapped to a group or position that gives you that privilege).

      In the following example, the Claims Handling organization unit’s scoped "View Work List" system action has a privilege assigned:

      In this example, a logged-in user who possesses the "Manage Work" privilege, can create a supervised work view for the Claims Handling organization unit.

      Note - The checking for needed system actions is hierarchical—for more information, see System Action Hierarchy.

  • Work items for an individual resource - This type of supervised work view contains all of the work items that are currently in the Inbox (unfiltered) of the resource for whom the supervised work view was set up.

    To be able to create this type of supervised work view:

    • A privilege must be assigned to the BRM.viewWorkList system action for a specific position to which the desired resource is mapped,
    • you must possess the privilege (and possible qualifier) assigned to the scoped BRM.viewWorkList system action for the position (you gain the privilege by being mapped to a group or position that gives you that privilege), and
    • you must possess the privilege (and possible qualifier) assigned to the DE.resourceAdmin system action (which is a system action available at the organization model level)—this gives you permission to list the resources so that you can choose one to supervise.

In the following example, a privilege has been assigned to the "View Work List" (BRM.viewWorkList) scoped system action on the Claims Handler position:

This allows a user who has the "Manage Work" privilege, with a qualifier of "Claims", to create a supervised work view for a user who has been mapped to the Claims Handler position (assuming the user creating the supervised work view also possesses a privilege assigned to the DE.resourceAdmin system action).

Note - The checking for needed system actions is hierarchical—for more information, see System Action Hierarchy.

System Action Hierarchy

The checking of system actions is hierarchical.

If different privileges are assigned to the same system action (e.g., BRM.viewWorkList) at different levels in the organization model, each level is checked when determining whether a user has the necessary privilege to be able to perform a particular system action. If the lowest level has no required privileges assigned, the parent entity is checked, and so on up the organization model hierarchy to the system-wide, organization model-level value.

For example, in the following diagram the "View work list" system action has been associated with three different privileges, "X", "Y" and "Z", at three different levels—the organization model, organization unit A, and position 2.

This means that a user who holds privilege "X", "Y" or "Z" can create a supervised work view:

  • for either Position 2 or Organization Unit A, or
  • for individual resources that have been mapped to Position 2.

If a user wants to view the work list of a user who holds Position 1, they must hold privilege "X" or "Y". This is because no privilege has been associated with Position 1, so any privileges associated with the parent entity are used instead. If privilege "Y" had not been associated with Organization Unit A, the user would instead need privilege "X", defined in the parent Organization Model.

As well as assigning different privileges at different levels, as shown above, qualifiers on the same privilege can be used to refine how access to a particular system action is controlled. (When comparing a required privilege to a held privilege, if either side is not qualified the comparison is positive. If both sides are qualified, the qualifications must match for the comparison to be positive.)

For more information about system actions, see the BPM Concepts guide.