AgilEntity Architecture: Action Oriented Workflow

Permissions, fine grained versus management headache

The usual method for determining which users can perform a given function on a given object in a managed system, employs providing those Users with specific access rights via the use of permissions. Often these permissions are also able to be granted to collections called Groups, to which Users are added. The combination of Permissions and Groups provides the ability to provide as atomic a dissemination of rights across the User space as possible. However, this granularity comes at the price of reduced efficiency for managing the created permissions and more importantly the Groups that collect Users designated to perform sets of actions. Essentially the Groups serve as access control lists in many systems, which for the variable and often changing environment of business applications means a need to constantly update the ACL’s (groups) in order to add or remove individuals based on their ability to perform certain actions. Also, the fact that the permissions systems are often designed to cover large areas of system control means they aren’t fine grained enough to be distributed to Users in a way , either by direct right or through group inclusion, so that certain Users are not given elevated permissions beyond what is intended. The converse of this problem is that when there is too much fine grained permissions, the size of the ACL’s goes up dramatically. The solution is to have the permissions scope varied for each type of object possible in the system.

• 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.

Variable scope permissions allow only the range of permissions to be given to particular Users that is desired for the types or instances to be managed. For example, to grant all permissions to all existing Entity types or any Entity types to be created in the future, one need only grant 16 Permissions to the User in question. These Permissions are the ones that allow any action on any Entity instance for each of the 8 actions to be discussed below, and 8 actions again for the System objects which have a separate Configure Permission set to manage them. Explicit permission to all objects of any type, implies implicit permission to instance of any type…allowing such Users to also grant their permissions to other Users in the system. Scoping allows Permissions to be granted exactly to conform to what is desired for a particular User without granting Permissions beyond what is desired. So such a system would make ACL management more efficient, but Action oriented Workflow goes further by eliminating the need for ACL’s entirely by embedding permission mediation into business workflows. This scope based permission system is pivotal to enabling the efficiency of the Action oriented Workflow paradigm that will now be introduced.

Atomic Actions

In designing the AgilEntity framework, the need to ensure an efficient and generalized permission scheme and management of Users in groups without incurring the inefficiencies of managing ACL’s was needed. It prompted a new idea in the management of User rights on the system. This new idea is wrapped around what is called an “action” in the AgilEntity framework. An action is defined as any request for execution of a particular function against an Entity object instance. The actions that can be performed against Entity instances are fixed in the API and are as follows:

Create

Edit

Publish

Delete

View

Search

Import

Export

These actions have specific meaning within the context of the Entity instance that they are invoked against. For example, it is possible when managing a “Story” Entity object to execute the “Import” action on a serialized version of the object from a specified location or to Export a serialized object to a specified location but the “search” action has no meaning to a Story Entity instance since there is no context for searching this type as of this date. It is possible, that redesign of the type at a later date may introduce a context where searching an instance is possible but currently, only entire type lists can be searched. The “create”, “edit”, “publish”, “delete” , “import” and “export” actions can be specifically delegated to other Users via the sending Users enabled Workflow.

A Workflow is a collection of Action Stages as specified by the 8 actions listed above, each stage can be given a set of Users who are delegated Agents to perform the requested action of the Stage. There is no guarantee that those Users can actually perform the requested action. The loose coupling between the Action Stages and the actual permissions of the Delegated Users associated with the Stage allows the action request to be malleable across Users in a way that is not possible with ACL’s. With an ACL, the execution of a function against an instance is User specific, such that if a User lacks the ability to perform a function, the story ends there. There is no built in method for those Users to either grant the request to some one who can perform the function or other wise notify them. In AgilEntity the “action” centric delegation of function requests across delegated Agents associated with stages for those actions makes this possible.

A User can attempt to perform a function and if they are part of a Workflow, their request for “action” can seek resolution by being navigated through a delegated agent space that spans across other Workflows. An initial request on the instance interrogates the User for classical permissions to perform the action, say “create a new User object”, this action can be performed in full by the User and a serialized instance of the desired object associated with the Users “action” request. If the User has permission to perform it, the action is submitted for execution immediately. If they are unable to perform the action, the Workflow engages for the “create” stage and the delegated agents for the Users Workflow are randomly selected for performing the action. The use of a random selection method ensures that delegates are sent requests for action in a non specific manner, since there is no guarantee that a chosen delegate can actually perform the “action” random selection is optimal for the automated explicit workflow. (An extension to the paradigm is planned that will enable the system to infer efficient agents that is called implicit workflow, as that implementation completes this section of the white paper will be augmented with the new capability.)

Fig. 1 A Workflow diagram showing an action originating with a Yellow User , navigating through several pink delegates and then finally being committed by a blue Delegated agent. This action resolution was contained entirely in the Action Stage of this workflow. Actions can flow between Workflows and allow arbitrary creation of complex business processes with a minimal need to grant permissions to Users.

Users with specific Manual delegation rights(an enabled attribute of User objects), can enter a specific User Delegate to submit an action to, this provides a direct line between an action request on a given object to a preferred User, who may be known to have the permission to perform the action, expediting the execution. In either event, both by automated workflow delegation or manual delegation, the action is sent to the delegates’ action Inbox, and if notification is enabled by the recipient, a notice of the action request is sent as well, allowing them to know with alacrity that a request for action has been received. The delegated User is now able to restore the serialized object associated with the requested “create” action and can chose to perform it as requested, in which case their Workflow logic is invoked complete with the same potential delegation to a different set of Users in the “create” Action stage of that workflow, or they can chose to manually delegate, or they can make a change and send the “action” request back to the originating User. The ability to embed a contingency for a given Delegates inability to perform an “action” greatly reduces the complexity of what would be necessary using ACL’s, as there is no longer a need to go outside of the Permissions scheme of the system to notify individuals with a permission or grant rights to a person without to perform a given action. The action request itself flows through a Delegate space of Users until someone is found who can do it, or knows who can do it. This is why this method is called an action oriented workflow. Traditional workflows, involve explicit listings of individuals in specific business processes, they can break if a request for action is incoming that can not be performed by any of the Users in the Workflow. In AgilEntity because different delegated agents can belong to different Workflows with completely different Delegated Agents in their stages , the hierarchy of the business can be modeled completely into the system, such that requests for action move toward individuals who can do them. A moment of thought reveals this to be precisely what happens in real world human workflow situations. Requests for action move to those who can do them, the action itself does not die once an individual is requested to do it that is incapable or not authorized to do it. By breaking this limitation on “actions” migration between User Workflows, the problem space of all existing business environments can be mapped by adequately designed Workflow schemes. Another major benefit is that User permissions can be designed so that separation of responsibility is built into the system, ensuring that no single User needs to be given “god” permissions on any action. Depending on the scope of the permissions, Users would be given Workflows that allow actions that require oversight to be first signed off by other Users. Thus a User who can not create objects can still be given the ability to construct the object in the interface and then send the create action against it to another User. As long as the User can view the Create interface they would only need to be added to a Workflow with Users that can actually commit the “create” action to be able to “create” by Proxy of these Delegates. Additional chaining of the actions through necessary Workflows can allow redundancies in case a given User is not available. The beauty of this paradigm is that there is no complex method for setting up the workflows, Users are added to the various stages and at run time, actions flow as directed by automated Workflow invocation and delegation and will converge on agents who can perform the action or can forward the action to agents that can. No single User needs to be a God, greatly simplifying the permission granting stage for Users and improving the security of all business processes.

Action Preview

An implicit aspect of action oriented workflows involves how the system serializes the suggested action on objects to file versions for each action request in the system. This allows several important efficiencies to be realized.

1. Multiple actions can be submitted for committal simultaneously by different Users.
2. 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.

Action Stream to a Users Timeline allows immediate notifications of performed actions to go out to all of a User contacts. These can be enforced as mandatory at the Site level or left to the Users discretion to enable, by ensuring that actions are shared with contacts the chance of concurrency clashes is reduced further.

These three advantages allow Users to essentially perform actions and then have those changes previewed by all delegates that view them in the Workflow chains that the action passes through before being committed. The Users can send back and forth memos as changes are made to the serialized versions of the object, allowing the action summaries created by the various Users to create a real time record of the changes. The following sections introduce additional features that enable even more efficient management for Users participating in Workflows.

Conservation of Permissions

A major issue with traditional permission schemes is the fact that Permissions are not conserved by default. Conservation of Permissions means that once a User grants a Permission they lose the right to apply that Permission themselves. Thus grant a permission is an implicit transfer of that right to another User. This is the default mode in real world security workflows…where a set of keys is handed over directly, it is not copied and then handed over. COP in the AOW paradigm prevents Users from continuously granting Permissions that they have to other User accounts and thus prevents runaway pathologies that can occur should a User account become compromised. The ability to delegate Permissions would be restricted by the enforcement of COP. Also, COP enforced User accounts must be more careful about the grant actions they are performing…a workflow of Users under COP ensure that Permissions across their interactions never grow beyond the current granted number of Permissions. Note, this doesn’t mean that granted Permissions can’t shrink they can as if Permission Tokens are assigned with the Permissions the tokens decrement with use and when finished the Permission can be revoked from the current User and thus effect a loss of Permission….from a security perspective this is ideal.

Efficient Workflow Design

With the creation of action oriented workflows, User actions can find the Users that are delegated to perform a given action against an Entity instance but how expeditiously this process converges on a User that can actually perform the action will vary depending on how the Workflow stages corresponding to the actions are designed. Ideally, the mapping should conform to existing business processes as they exist in the real world business. An example best serves to illustrate this. Suppose the sales team consists of the VP of Sales and 3 low level agents. Ad campaigns are created and edited by the Sales agents and then when ready, sent to the VP of Sales for publishing to a consumer facing Site. Assuming that the Entity type is called “Campaign”, the Workflow for the Agents would consist of a Create and Edit stage that have each of the other Agents in the stage as well. This would allow each agent to forward “create” or “edit” actions to their partner agents if they are unable to perform the requested create or edit action or if they are collaborating on the “campaign” together and need to exchange feedback. Once a campaign object is ready to go to the VP it is submitted through the publish stage which would contain the VP as an agent. The action could also be sent to the VP directly if the agents are given manual delegation permissions but assume none of the agents have this permission. If the Publish Stage of the Agents does not contain the VP there is no way for the publish action to ever get to someone (the VP being the only person) who can perform it. Now let us assume the VP exists in the agent workflow, let us also assume that the VP’s workflow is different from the agents. When the VP receives a publish action request from her agents, her publish workflow can be engaged through delegation and send the request to another user, say the President of Sales. The publish stages that the VP and President are members of can be different from that in which the VP and the agents are a member of. In fact, a User can be a member (as delegate) of an arbitrary number of Stages for an action each belonging to a different Workflow. Again, the loose coupling of delegation from actual permission to perform the action ensures that action requests flow to a User that can perform them but only if at least one gateway User exists in each stage when actions must flow between Workflow stages. Gateway Users are not required for Stages where the committing User is in the same Stage.

Fig. 2: This illustrates flow of an action between two Workflows. The action stage being navigated is the “create” stage, which for both Workflows contains a unique number of Users. Users need not be Unique between Stages, a User can exist in multiple Stages for different Workflows but can only delegate to one Workflow at a time. This allows any action to cross Workflow stages using Gateways to find Users that can commit the action. Here, the action goes to a second Workflow, is passed between two delegates and then passed back to the originating Workflow for commitment by one of its Agents.

Thus the VP serves as a gateway agent for the publish action of the agents workflow. The presence of that User allows create/edit requests to be sent on to the President who actually commits the publish action to the system. Every stage should have at least 1 gateway User to ensure that delegated actions within Stages always converge on an agent that can perform the action. In a real business process, the ability to determine who has the permission to do something can be changed readily, such as if some one goes on vacation. In this case some external means of routing the changes to the Users must be designed. In AgilEntity, the ability to modify the Stages (they are Entities) and delay Delegated Agent status for them allows this simple business change to be easily injected into a real time workflow at any time desired. If for example, the VP of sales goes on vacation for two weeks. The agents will need to be able to forward the request to publish directly to the President, this can be accomplished by either having the agents directly send the request by allowing them to manually delegate. However this provides manual delegation for all Stages and that power may not be desired, the next option is to change the Workflow of one or all of the agents temporarily so that a new Workflow with the publish stage containing the President of Sales is associated with the User agents. Thus subsequent publish action submits by the Agents will be routed to the President instead of the VP who is on vacation. The use of Flags (mentioned in next section) enables automating the changes so that the Workflows are changed when the VP starts vacation and then automatically changed back when the VP is scheduled to return. So ultimately, efficient Workflow and Stage design involves simply modeling for the contingencies of real world teams by ensuring that each Stage has a User agent that can either perform or route an action to some other User that can perform the action. Setting up at least two gateway Agents helps mitigate against failure of one User to perform an action requested and even when a gateway is not available, Workflow stage Agents can be dynamically changed to promote Users to become Gateways.

-->

Fig. 3 This illustrates a multi-Workflow resolution of a Create action requested. Since there is no a priori knowledge of who will be committing an action, the action can flow across multiple Workflows to find an agent who is authorized to perform it. Note, though three Workflows are shown here, any number of Workflows can be involved, also actions can flow, from any Workflow to any other as long as the delegate can send the action either automatically or by manual delegation to an available User in another Workflow.

In real world business workflows, Users are not always available to perform actions. People have sick leave and go on vacations or business trips. How can the system efficiently model this highly variable transitory requirement for actions being rerouted around Users who are not available to handle them? The system is designed to perform an implicit view Permission check of any selected User Delegate for a given Workflow stage. This ensures that the delegate is able to at least perform the View action on the requested object, this is important as , a User who can not view an object will be unable to forward that action request to another User or back to the sender, by ensuring implicit View , only implicit Viewers can be delegates. Checking for implicit view permissions of an action request sent to a Delegate almost makes sure that the User can view the action at the time the request is sent but it can not guarantee that the delegate will still have the implicit View permission once the User views their action Inbox to process actions. It is possible that the Users account Permissions are changed between being sent an action request and handling it for example, in this case a User without implicit view would still have the action in their inbox. To handle this pathology, the system allows the User to redirect the action to the originator without having to view it, this bounces it back to the sender and allows them to re-delegate the action if desired. This behavior mimics what happens in the real world, if you ask a coworker to do something you first make sure (implicitly) that they can, if they can not you don’t ask (logically same as giving the request in a locked box , and then having it handed back due to lacking key ( permissions) to open it and view the folder) The difference being is that in AgilEntity this happens automatically. Another important consideration must be made when a User goes on vacation, if they are not available to handle an action but are sent that action in a workflow and have implicit view Permission, the entire duration of their vacation or business trip or sick leave can elapse before an important action is addressed. One way to handle this is to remove the User as a delegate from any Stages he/she may participate in. For small number of Stages this is acceptable, but what if a User appears in many different stages? The system can virtually remove a User from a Stage delegation circle by deactivating the Users account, this can be automated to be initialized on the day the User starts vacation and then to be revoked on the day they come back. The deactivated User would be unable to login to the system during the duration but would still be able to receive email notifications and would still be able to collaborate on the system as a guest in room. 

So the system has two robust methods to prevent delegation pathologies, implicit view enforcement and rebouncing and the temporary removal of an individual from a Stage during their leave term, but what if one doesn’t want to remove a User from any Stage?? The system also enables User accounts to be marked as Workflow Offline Rerouting. These User accounts are not considered during action delegation events as their current logged in status is evaluated to determine if the work will go to the User. Thus the system will only route to Users that are available in the Stage selection process. In the extension to the AOW paradigm that enables implicit Workflows with artificially intelligent agent selection this feature will be critical as is discussed in the next section on Implicit Workflow.  The combination of features here makes it very efficient to route actions around Users who are not available , turning what in real businesses is an affair that requires setting up complex contingencies into something that is automatically handled by the system simply by specifying that the User is not active for a given date interval or is removed from stages or in combination with the other methods, is rerouted for workflow delegation when offline.

Implicit Workflow

It is clear from the previous sections that Action Oriented Workflow replaces the tedious process of constructing workflows using business rules and business process languages with a graphical web based solution. The ability to simply group desired potential users into Stages of potential action execution for a given Action and then group those Stages into Workflows through which different Users can participate creates a the necessary lose coupling that provides a very dynamic and self healing workflow modeling process for any type of business without needing any code to be written. This process of explicit workflow construction however requires time and research on the part of the business in order to model the existing workflows between workers in the system and creating associated Workflows and Stages that model those real world workflows using AOW. The question then becomes is there a way to simplify the act of capturing the action workflows more expediently?

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.

Action Delta Assessment Algorithm (ADA)

When looking at any particular object from the AOW perspective what we see are actions being performed against the object by particular agents, the agents don’t always have the ability to commit those actions and explicit workflows allow convergence of requested action on individuals that can perform them if the Workflows are properly designed. However in explicit AOW the information of completed actions is not utilized. Implicit workflow requires the gathering of historical data on the completion of past actions against particular objects by particular agents and uses that information to compile a map of the action landscape navigated by the User agent that can be used to infer from agent to agent, which agents have been most efficient at performing the requested action in the past.

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.

Workflow Filtering

A final and important management control for Workflows that stream lines workflow design involves filtering of the display of action buttons in the UI based on the available Stages in the Users workflow. If a given User has permissions to edit an object having the permission is necessary but not sufficient for them to actually be able to submit a request to edit through the interface. This requires a second factor in the Workflow of the User being true, the Workflow must contain a Stage that is activated for the Action being requested. If the Workflow lacks the Stage then the User is not even aware of the their ability to perform the Action through the interface. This allows a restricted view of the Workflow submit buttons to be displayed to certain Users without requiring explicit removal of permissions from the User account. This could be desirable in situations where a collection of Users (say a Sales Team or a Biz Dev Team) all need to have their ability to apply a given action changed. Without Filtering each member of the required teams would need to have their individual Permissions changed. (This could be automated some what if they all have a permission set but what if there are two different teams with two different sets of Permissions?) in such cases simply modifying the Workflow to include or exclude Action Stages that are important for the teams to be able to engage will allow both groups to have their permissions filtered in application. Thus separation of responsibility extends into the interface such that only those individuals who’s current Workflow allows them to view Action submit fields by having a Stage for the Action can do so if they also have the implicit or explicit permission to do so. Thus large collections of Users sharing different Permissions against different types can have their abilities modulated together easily. This significantly reduces the complexity of setting up Workflows that serve special purposes and improves the efficiency and dynamism of the active business processes.

Efficiency

In a traditional scheme that lacks an ability to delegate actions through a workflow, each User is given a set of permissions, with the possibility that some Users can have the same permission. The total number of possible permissions granted in this system will rise as a function of the total number of users.

Tpg = ns * k

Tpg = Total permissions granted to all Users.

ns = Total number of Users in system.

k = Total number of unique permissions available to grant.

This clearly shows the linear scaling of the number of granted permissions in such a system that shows it blows up fairly quickly. It also shows that in a system with each User given every permission, the number of delegations required to perform an action is 0. Since every User can perform every action. This contrasts with the variable delegations required when using AOW that depends on the workflow design choices.

In order to compare the efficiency to one that employs the action oriented workflow described previously, we will redefine the total number of Users in system ns as a ratio of the total number of Users over the total number of Users minus the total number of Users minus the total number of Users with more than one permission.

ns = n/[n – (n – wp)]

wp = Total number of Users with exactly 1 permission

(n – wp) = Total number of Users with more than 1 Permission.

ns = n/ [n – n + wp] = n/ wp

and thus Tpg generalized becomes:

Tgp = (n/wp)k

When wp is equal to n , every User has exactly 1 unique permission, and thus every action requested has only one person who can perform it but n – 1 people who can only delegate it. As the number of Users n goes up, the number of required delegations goes up as well. Thus the number of permissions required for all Users goes down to:

If wp = n

ns = n/n = 1

Tpg = (n/n) k = k

: the number of delegations goes up to a maximum of n – 1 for AOW that assumes Users engaged in automated Workflows. The parameter k itself is a function of the number of actions on the system multiplied by the number of Entity types as follows:

k = m * a

m = Total Number of Entity types on the system for a given permission scope.

a = Total number of actions that can be performed.

For all Entities the number of actions is 8 as described in the atomic actions section above, thus:

k = m * 8

System permissions have one less action granted in permission form. The “search” action is meaningless from the system perspective so there are only 7 of those. Excluding system permissions scope, the minimum number of permissions granted varies with the Entity scope.

For the current number of Entity types in a default AgilEntity installation, the total permissions granted of each specific type are:

Tpg = m_all of type * 8 = 42 * 8 = 336

The 42 indicating the number of unique types in the default installation of an AgilEntity cluster. As new types are added to the system, they will augment the total permissions by 8 , 1 for each action for all instances of the new type. This reduces significantly if we grant permissions for all BaseEntity types, which are constant over the number of Entity types:

Tpg = m_all of all types * 8 = 1 * 8 = 8

Finally, instance permissions can be granted for each instance of any type on a per instance basis. These permissions are created prior to being granted to Users, thus permissions are generated only when a User space need necessitates their creation. There is no maximum grant value as a result.

Several trade offs are now apparent:

• 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.

Delayed Action execution using Flags

In many classical systems, even when a User has the permission to perform a given action, often there is a need to delay the execution of that action for some time in the future. Such systems are usually designed to have specific delay logic for the specific action requested on the type that is being managed. This hard coding of specific delay logic for specific types makes these systems extremely inflexible, for example, use of the delay logic can not be generalized to apply to any instance of any type of managed object. In AgilEntity, there is an orthogonal API for allowing actions requested through the API to be delayed for execution at a later date by the automated DAD (delayed action daemon) thread that can run on every AgilEntity node instance. DAD can perform every action explicitly and has the ability to view and search implicitly. Users specify an action for delayed execution independently on the objects edit page using what is also a managed Entity in the system called a Flag. Flags, essentially atomize time, they also atomize date and can be used as a filtering mechanism for Entity types themselves. A Flag has 3 states depending on the date and times specified in its start and end date/time fields and the current date and time on the executing Node. The system checks against the date times and determines the 3 states possible for a Flag.

• 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.

In the Workflow API, they are used to atomize date and time by specifying valid date or time intervals over which a specific action should be performed. When associated with a delegated action request, a Flag can be made to perform that “action” once or as many times as desired by specifying specific periodicity attributes with the Flag. Thus, using the example above for creating a “story”, the action request would flow through the Workflows of User Delegates until it finds a User who can perform the action and is willing to do so, assuming the serialized object for the “create” action had a delay Flag attached as well indicating that the create action should happen 2 weeks hence, rather than immediately. The User would submit the “create” action and if the date/time of submission is prior to the delay Flag’s Freshness date (meaning the Flag is currently Nascent) the action request will automatically be routed to the DAD , DAQ (delay actions queue) table, which specifies the details of the action to perform. Once in the DAQ queue, DAD threads potentially running on every AgilEntity node, will periodically scan the queue as determined by each Node for delayed actions with Fresh Flags to execute. Flags can be made to be Fresh between specific times of a range of dates, or they can be specified to recur only on specific days. The range of periodicity allows a full mapping of the problem space of any business application, essentially DAD becomes a proxy User for live human agents, enabling them to efficiently perform actions on objects in real time but also to designate those actions to perform in future time as well without introducing additional complexity into the system. The addition of new Entity types is completely independent of the Workflow and delay Flag sub API’s and would automatically be available for use on new types without any additional code. The use of actions and an action oriented workflow enables a new ability to manage the events of a business process to unprecedented detail. Because only individuals who are permitted to perform various actions can actually do them, action requests can move from delegated User to delegated User in or between Workflow Stages, until some one with the necessary implicit Permission performs them. The API records when actions are performed and who performs them in an Entity independent manner, so it is possible to track execution of actions from the perspective both of the Users that perform them and as well from the perspective of the actual objects over which those actions are being done, by simply reporting the execution of actions against objects. The AgilEntity framework does this using what are called object LifeCycles which are discussed in a following section.

Permission Tokens: Eliminating the postal anomaly

The four scope models listed in the first section of this paper for enabling granularity for Entities, are sufficient to cover a wide range of possible uses in real live businesses. Using them, Users can be granted action commitment capability for particular instances, all instances of an Entity, all instances of all Entities or all System Objects thus allowing the entire platform to be managed. However, often being able to assign permissions isn’t enough, the Delay Flags allow an additional dimension of control often required in businesses to be independently managed,that is time. Flags can be used to restrict User access to particular dates or time or can be used to perform complex removal or addition of permissions by delegating such actions to DAD. The managed User objects would then be subject to dynamic modification of their permissions scope by Flags but even this is often not good enough. There is still the possibility that a User goes “postal” and during their authorized date or time interval, performs a permitted action excessively because that account has been compromised in some way. How do we further limit access for Permissions within Flagged date or time intervals? The answer is Permission Tokens, Permission Tokens associate a use count of tokens, or allowed action commitments for a particular Entity Permission of any scope. This allows us to set limitations on the number of times an action Permission can occur by a User once granted. Tokens can be set to provide say 10 uses of the edit Permission for any Story object within an interval of time or dates by Flag enforcement. If the Tokens are utilized before the interval is reached, the Permission is revoked, this prevents possible run away use of a Permission by setting acceptable use bounds on invocation of an action across all Permission scopes. Tokens are orthogonal to the existing 4 scopes and the date and time granulation of Flags, thus expanding the potential of simulated business security conditions to cover any possible use. The useful nature of such a system has been realized in the Entity Management and Collaboration applications build on the AgilEntity platform. Any commercial sites built on the platform can use permission tokens to grant precise use behavior for an Entity (Conversation) enabling Users to create their own Conversations as determined by the service plan the User purchases on the site. The Site automatically sets the tokens for the Permission and associates them with the User. The User is free to use the tokens at any time, but once fully utilized the Permission is revoked. This allows us to grant Permissions temporarily to Users without having to use Flags to delegate actions to a Workflow, it also allows us to precisely meter use of the application, as in theory we could provide service by collecting particular Token bundles of access to different Entities. Easily enabling the system to provide limited trial accounts for new services (let them use this 4 times then take it away…etc.) as well as other complex behaviors.

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.

Life Cycles: Monitoring who performs actions on Objects

We have seen how the combination of fine grained permissions with permission scope across all Entity types or instances allows us to define precisely the set of capabilities that are required on business objects. The creation of Action oriented workflows that delegate actions on objects to Users without knowing if those Users can actually perform them, enables loose coupling between a request for an action on an object that must be done, from the actual person who does it. If the delegate is unable to perform it, good workflow design , as is the case in good business process practice in real world businesses, requires that the action be passed on to some one who can. The Use of gateway Users in Workflow stages for particular actions, allows existing business processes to be easily and perfectly mapped into the AgilEntity workflow system. The use of Flags provides the ability to delay actions for execution by the system DAD process in various ways, either for single or multiple invocations and at any desired date and time parameters required of the business. These various features necessitate a management system for actions on objects, such that monitoring of action execution can be performed from two perspectives.

• From the perspective of the Users performing the actions.
• From the perspective of the Objects over which actions are being performed.

Most systems enable by virtue of their design, an ability to track User actions and AgilEntity has an extensive system for tracking tasks executed by a particular User once that User is logged into the system. This allows those wishing to monitor actions performed by particular Users to subscribe to the Action Reports of these Users once they egress from the system. This system allows reporting of particular Users behavior on the system which enables system managers to determine if they are performing authorized activities on the system. However, the more important monitoring task from the perspective of a running business, is not to determine just who is doing potentially nefarious things on the system, it is to determine who is doing their designated jobs and how efficiently are they doing them. This latter problem has been extremely difficult to build into systems software designed to manage actions across many types of vertical industries. A general solution however that is able to be utilized against any object type and there for could be injected with the needs of any particular vertical has not been designed until now. Because all action executions on all instances of all types of Entity objects are managed by the framework, these actions can be used to trigger tracking for particular objects. AgilEntity does this by using an existing Entity type to write action executions for each object instance that has LifeCycles turned on. The management object is called a Log and maps to a physical file, it has the ability to have entries written to it in various ways (text, xml) by using this object and associating one with every instance of any managed object in the system, the actions performed against objects can be managed per object. Additionally, because the Log class has the ability to notify a set of Users when certain entries are written, it is possible to have the LifeCycle dynamically modified to notify individuals when actions are performed against the associated object instance. This works for every instance of any type, the actual Log objects used to manage LifeCycles are themselves not managed in the system datastore as formal Entity objects. The managed Log Entities are used to manage writing of entries to the system log files of the framework and applications developed on it. Using the same class to perform Life Cycle monitoring eliminates otherwise required code to perform the function. Once LifeCycle monitoring is turned on for an object, Users that subscribe to the LifeCycle can receive email notifications of actions performed against it. Implicitly, only Users with the ability to View an object instance can subscribe to the LifeCycle, only Users that have the implicit Edit action against an object can turn on or off LifeCycle monitoring (with the enabling or disabling of the monitoring itself being reported to the LifeCycle for the object). Detailed reports on action executions can thus be created and reports generated to indicate who requested various actions and who executed those actions. LifeCycles include actions performed by DAD as well, allowing execution reports to be made that allow ready data extraction such as the following on ANY instance of any type:

• 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.

The previous data extractions are critical to allowing businesses to determine which Users are most effective and which workflows are most efficient. If for example it is found that a given workflow induces a delegation to a User who can not perform an action but can forward it on to some one who does, this can be spotted by looking at the LifeCycle of the mediated object. Excessive re-delegations of actions are targets for modification of the Workflow that could improve the efficiency of the workflow and the corresponding real world business process. Also, because any User who can View an object can subscribe to its LifeCycle, managers can watch actions performing against important objects in the system without needing to actually take part in action resolution. This real time visualization of workflows actually allows reducing the number of reports needed as managers can subscribe precisely to the objects that are most important for their job specification, and take action when the monitored LifeCycles indicate the need for their assistance.

Summary

The development of action oriented Workflows with delayed Flags and Permission Tokens enables the AgilEntity framework to model any possible business process and User permissions scheme. It provides a highly manageable paradigm for ensuring that actions against specific instances of managed Entity types converge on the Users that can perform those actions. The delay Flags allow actions to further be cast into the future for execution by DAD if immediate execution is not required. This enables actions to be submitted to be performed by any User and thus reduce the load of possible requests on a Users Action Inbox awaiting execution. Since the User can take a current request and if it is not an urgent one, set it to be performed automatically by DAD at some time in the future. This removes a significant pressure from the User agents particularly in high pressure business processes where many requests are being made for action. The ability to send notifications using LifeCycles when actions are submitted provides a method to ensure alacrity in execution. It also provides a ready metric for determining the efficiency of execution of particular User interactions, allowing workflows to be gauged for their overall efficiency for the business. Visualizing workflows and assigning metrics to them, makes streamlining the corresponding business processes trivial. The AgilEntity platform will run the WorkNetz.com cluster of servers. The action oriented workflow allows the management of action requests from the User space by a very small number of individuals while ensuring visibility to all requests. For example, WorkNetz.com has service plan options that allow Users to manage their own portal Site. The administrating User of each Site plan is given permission to create/view/edit/delete certain Entity instances either personally or by delegation. For example, administrators can view instances of their Site object but they can edit the Site only through delegation (using AOW) to the designated cluster manager(s). Currently this is only one person, as requests for actions on different sites are made; those actions are all delegated to this one User who receives email notification of each request the moment it is made. This minimizes the number of individuals needed to manage large numbers of requests and reduces the business operating costs significantly. The Site plan purchasers are allowed to perform other actions on other Entity types without delegation, for example they can edit their own Workflows and Stages to disseminate to Users that are created by delegation. Administratively, the establishment of service plan duration is done using AOW and DAD actions. Service Plans are tied to the administrating Site activity parameter which is associated with a Flag. The Flag “freshness” interval is set to match the purchased plan and the action entered into the DAQ, in this case to deactivate the Site when the Flag is found to be in its “fresh” period. Intermediate code for sending notification emails as a plan duration runs its course lead up to the eventual date that the delayed action is retrieved from the DAQ queue by a DAD instance running on one of the cluster nodes and executed. Thus DAD instances on nodes serve as delegated agents for the service plan deactivate action associated with the administrated Site, invalidating further access to the Site by any of its Users. Other service plans enable limited ability to perform actions on objects for Users that purchase them using Permission Tokens, this allows action atomized limited trials of various service features. Since the action oriented workflow features described in this document are core to the framework, they are agnostic to the applications built on the framework and thus can be leveraged automatically without integration code. This has enabled the development and inclusion of complex new features into the initial applications with no downtime. The pending launch of the site and exposure to internet load will be the true test of the efficiency of the AOW methodology. Apriority will be producing additional documentation in the future that analyzes the internet loaded performance.