- Permissions for actions performed to particular object instances of an Entity type.
- Permissions for actions performed to any object instance of a single Entity type.
- Permissions for actions performed to any object instance of any Entity type.
- Permissions for actions performed to any object instance of any System objects that may or may not also be Entity types.
- Multiple actions can be submitted for committal simultaneously by different Users.
- Since multiple serialized versions are created for each requested action on an object, there is no need for a check out/ check in sub API nor are any such pathologies possible. It is possible for multiple version to be submitted but the visibility of action submit requests by various agents via lifecycle monitoring makes it unlikely that changes would actually be submitted by editors of a given object without reciprocal notification.
Looking at the process described above the key task is in recognizing the individuals from the real world workflow that have a given permission to a permission type of object and then placing those individuals into the Stages of the Workflows that will have them interact with people that they either send or receive work actions to. This process of selecting can actually be automated using a machine learning approach. Implicit workflow introduces the concept of Action Delta Assessment to automate this step.
The implicit Workflow then proceeds not by requiring explicit description of agents to Stages but instead uses the existing agents list of Contacts. Since AOW uses a social model for connecting agents that model defines the work relationships in a business most precisely. User agents would simply connect in the ways that model the existing relationships and then the Implicit workflow system will automatically utilize each Users contact list to infer Agent delivery when actions are requested. There is thus no need to populate Stages with agents explicitly, Workflows can be indicated as “implicit” and the existing Contacts list for the User will be used for the indicated action for all Objects that are encountered. This is far more efficient as well because there is no research process needed on the part of the Workflow creator to find out which agents are able to perform given tasks…the system using ADA will figure it out as people perform and route actions.
ADA enables a truly unique learning process for the workflow system, it learns the best agents for a given requested action and dynamically routes to those agents if they are available. As described in the last section of Efficient Explicit Workflow design the new feature for workflow offline rerouting enables ADA to discount individuals that are not currently on the system this is very important as it enables Users to opt out of active action delta assessment calculations by having actions routed around their action inbox when they are not online. This solves the problem of having user agents piling up important work actions in their inbox and allows actions to continue to flow only to *available* agents. This solution is more than just useful for keeping actions moving until convergence it also makes it possible for the agents to opt in or opt out of work without having their action delta calculations be changed. Using ADA and WOR agents could meritocratically perform the work they wish to perform on their own time line and be merited only for that performed work. When they are online they are by definition expressing availability to work and are more likely to accept and start actions or route them onward to others. If however they chose to stay hidden from the system they can do so and the system will not punish them for not being available. The ability for the system to remember efficient agents upon their availability frees the agent to be most productive when they chose to work and thus ensures the best work is *always done* by the best available agents.
- Automated AOW trades a linear ramp in granted Permissions across all Users for a linear ramp in delegated actions between all Users participating in Workflows.
- Manual AOW trades the linear ramp in granted Permissions across all Users for a constant delegation count IF the Users are aware of those Users that can perform an action they wish to have performed by sending the action directly to those Users.
- Without AOW, some Users can give rise to the “postal anomaly” where they use their advanced permissions to compromise the system in some way. With AOW, depending on the level of permission delegation, with a maximum reached when wp = n as shown above, the postal anomaly is made impossible.
- With AOW, some delegated actions can be given specific minimum commit times by ensuring as many or as few delegations as necessary as the action converges through designed Workflow stages.
- Variable delegation of actions to stages for each action in a Workflow allows the penalty of time to commit to be adjusted as tolerable for the mapped business process.
- Once all permissions are represented with at least one User that performs the action, no additional User needs to have a permission granted. The granted Permissions curve can become a constant with good Workflow design.
- Since the number of actions is constant and the number of Entity types changes slowly compared to the number of Users, Workflows need not be adjusted to reflect changes in the number of Entity types. As new types are added to the system they will implicitly be delegatable through existing Workflows since action is managed agnostically of the associated Entity types. The 8 possible actions simply need be granted to at least 8 separate Users and all existing Users that participate in Workflows can be linked so that action requests eventually converge to the delegated Users that actually have the permission to perform the action.
- If the current date /time is prior to the date/time attribute of the Flag the Flag is listed as Nascent.
- If the current date/time is between the Flags start /end, date /time attributes the Flag is listed as Fresh.
- If the current date/time is after the Flags start/end, date/time attributes the Flag is listed as Expired.
The previously mentioned Conservation of Permissions feature also makes the postal anomaly difficult by restricting delegation capabilities to permission transfers only.This prevents compromised accounts from possibly cloning new accounts or existing permissions for further nefarious exploitation of the system. As COP is enabled system wide in a binary fashion, if it is disabled the advantages mitigating against the postal anomaly are only those regarding token limitations mentioned above.
- From the perspective of the Users performing the actions.
- From the perspective of the Objects over which actions are being performed.
- Determine if Users charged with any action on any type are doing it in a timely manner.
- Determine if a User delegated an action to DAD for delayed execution.
- Determine when DAD executes a previously delegated action and from which User the action request originated .
- Create a way to intrinsically gauge the efficiency of Users, allowing bonus or salary to be tied directly to actions performed against business objects in a timely manner.
- Track who is viewing an objects history or otherwise interacting with it.