Use Case I - Interdepartmental Privileging Approvals
perMIT does not have embedded workflow. In the mid 1990s one of the early design decisions was that a person who can grant a privilge, can be restricted to grant specific functions within specific portions of the scope hierarchy. However, they are not restricted regarding who they grant the privilege to.
If a particular department, lab, or center, decided that they wanted a process that works as decribed by NCSU Use Case I, we would recommend implementing it as a separate application. We would create a new category and set up new functions such as Privilege Requestor and Privilege Approver. We would use perMIT to manage the workflow roles, but the external application would manage the actuall workflow of the requests, notifications, and approvals. The external application would have the privileges necessary to actually populate the approved privileges into perMIT.
Since the workflow management of this functionality doesn't multiple applications, it is only managing what appears in perMIT, an enterprise workflow system is not needed. This could be implemented in GrailsFlow or some other self contained workflow creation framework very easily.
Use Case II - Interdepartmental Privilege Scoping
perMIT does not suffer from the limitation described in this use case. The only way this type of problem would exist was if both Chemical Engineering and Nuclear Engineering were in the same school, and some inadvertantly assigned Sally the "payroll clerk" function at the school level instead of the departmental level. This would be easy to adjust, once noticed.
Please note that the Oracle version of perMIT, known as Roles, is in production at MIT and it is used to manage privileges and access control within our SAP deployment. HR/Payroll uses our instance of SAP. The MIT deployment does not suffer from the limitations desceibed in NCSU Use Case II.