Best Practices from Oracle Development's A‑Team

BPM 11g - Case Management In-Depth: Stakeholders and Permissions

Mark Foster

We've seen in the previous 3 posts in this series what Case Management is, how it can be configured in BPM Studio and its lifecycle.

I now want to go into some more depth with specific areas such as....

  • Stakeholders & Permissions
  • Case Activities
  • Case Rules
  • ...etc.

... as, in the process of designing a Case Management solution it is important to know what approach to take, what questions to ask and based on the answers to these questions, how to implement. I'll start with Stakeholders & Permissions.


The users that perform actions on case objects, defined at a business level, e.g. “Help Desk Agent”, “Help Desk Supervisor” etc...


These result in roles in “OracleBPMProcessRolesApp”....


LDAP groups/users etc... can be assigned to these.


Are applied at the level of Stakeholders and Tags....

Stakeholder Permissions

These are NOT the permissions found in the “Stakeholders & Permissions” tab in Studio.

Stakeholder permissions are READ, UPDATE & INVOKE where READ/UPDATE apply to the following objects: Case, Comment, Document, Data, Milestone, Stakeholder, Header & INVOKE applies to Event & Activity.

By default on deployment all stakeholders have all permissions...


....it will almost certainly be necessary to remove some of these permissions post-deployment, for example “HelpDeskReviewer” probably should not be able to INVOKE or UPDATE anything.

Tag Permissions

These are the permissions found in the “Stakeholders & Permissions” tab in Studio. They default to “Public” & “Restricted” but others can be added as required....

...and they surface as application roles....


It would make sense that here “HelpDeskReviewer” and others have PUBLIC.READ.Role, but that “HelpDeskAgent” has “PUBLIC.INVOKE.Role” etc...

These Tag Permissions can be attached to case objects, for example a case activity....


...i.e. this activity can be invoked by “PUBLIC”... which means that if a user/group/application role is a member of “PUBLIC.INVOKE.Role” then they can invoke this particular activity. In our case we used application role “HelpDeskAgent” and this had Stakeholder permission of INVOKE.

These tags can also be attached to other case objects, for example, when attaching a document to a case the tag can be specified etc...



Now we understand stakeholders & permissions, how can we approach defining these in a Case Management project ? I have found it useful to cross-reference stakeholder & tag permissions with the stakeholders themselves, this provides a concise and obvious view of their relationships, and is immediately understandable by the business.

Consider the following x-ref....


....examples would be:

  • Only HelpDeskSupervisors can read/update highly confidential comments
  • Only HelpDeskAgents or HelpDeskSupervisor can invoke restricted activities
  • There is no concept of highly confidential milestones
  • HelpDeskReviewers can only read public case objects


In essence Stakeholder Permissions are broad-grained, e.g. HelpDeskReviewer cannot invoke anything, whereas Tag Permissions layered on top of these provide finer granularity at the level of individual case objects, e.g. HelpDeskReviewer can only view PUBLIC documents.

Coming Next

Now that we have looked at Stakeholders & Permissions, in the next blog entry we'll look at Case Activities.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha