Patent Application
20220083679
This disclosure relates to content management systems, and more particularly to techniques for implementing broker-assisted workflows.
Many traditional file systems support file/folder hierarchies that inherit permissions from a hierarchically higher object in the hierarchy. This is fine in many settings, however in some situations a logical hierarchy of folders (e.g., “Customers”->{“Customer #1”, “Customer #2”, “Customer #3”}) that have such inherited permissions might be too permissive. For example, while it might be appropriate for a Vice President to have access to the “Customers” folder (e.g., all of “Customer #1”, “Customer #2”, “Customer #3”, etc.), it might be too permissive for an outside contractor or consultant to have access to all of the contents of {“Customer #1”, “Customer #2”, “Customer #3”, etc.}. It might be more appropriate for the outside contractor or consultant to have access to only the contents of one customer folder, namely that customer for whom the outside contractor or consultant is performing work. This can be accomplished using legacy permissions models.
While such limitations of accesses can be set up using legacy permissions models applied to specific customer folders with respect to specific users (e.g., the contractors or consultants), it introduces unwanted side effects. For example, a business process that has been designed and implemented (e.g., as a workflow) for “Customer #1” might be 100% appropriate to apply to “Customer #2”; however, to the extent that the business process (e.g., workflow) is stored in the folder hierarchy of “Customer #1”, and to the extent that the contractor or consultant is only permitted to see and operate over the folder hierarchy of “Customer #2”, this brings about an administrative conundrum: Either the contractor or consultant associated with the folder hierarchy of “Customer #2” is granted access to the folder hierarchy of “Customer #1”, or the business process in the folder hierarchy of “Customer #1” would have to be copied into the folder hierarchy of “Customer #2”.
Unfortunately, the foregoing approaches lead to sub-optimal results. In particular, copying of workflows is fatally sub-optimal, at least inasmuch as having multiple copies of workflow objects (e.g., scripts, code, etc.) creates a maintenance/management nightmare. What is needed is a technique or techniques that address how to execute a workflow in multiple mutually-exclusive user contexts without making copies of the workflow into the multiple mutually-exclusive user contexts.
This summary is provided to introduce a selection of concepts that are further described elsewhere in the written description and in the figures. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Moreover, the individual embodiments of this disclosure each have several innovative aspects, no single one of which is solely responsible for any particular desirable attribute or end result.
The present disclosure describes techniques used in systems, methods, and in computer program products for implementing broker-assisted workflows, which techniques advance the relevant technologies to address technological issues with legacy approaches. Portions of the present disclosure describe techniques used in systems, methods, and in computer program products for implementing broker-assisted workflows. Certain embodiments are directed to technological solutions for forwarding a workflow trigger to a computer-implemented agent that executes the workflow on behalf of an initiator.
The disclosed embodiments modify and improve over legacy approaches. In particular, the herein-disclosed techniques provide technical solutions that address the technical problems attendant to executing a workflow in multiple mutually-exclusive user contexts without copying the workflow into the multiple mutually-exclusive user contexts. Such technical solutions involve specific implementations (i.e., data organization, data communication paths, module-to-module interrelationships, etc.) that relate to the software arts for improving computer functionality.
The herein-disclosed embodiments include forwarding a workflow trigger to a computer-implemented agent that executes the workflow on behalf of the initiator. The embodiments involve technological solutions pertaining to technological problems that arise in the hardware and software arts that underlie content management systems. Aspects of the present disclosure achieve performance and other improvements in peripheral technical fields including, but not limited to, workflow deployment and document storage.
Some embodiments include a sequence of instructions that are stored on a non-transitory computer readable medium. Such a sequence of instructions, when stored in memory and executed by one or more processors causes the one or more processors to perform a set of acts that forward a workflow trigger to a computer-implemented agent that executes the workflow on behalf of the initiator.
Some embodiments include the aforementioned sequence of instructions that are stored in a memory, which memory is interfaced to one or more processors such that the one or more processors can execute the sequence of instructions to cause the one or more processors to implement acts that forward a workflow trigger to a computer-implemented agent that executes the workflow on behalf of the initiator.
In various embodiments, any combinations of any of the above can be combined to perform any variations of acts for implementing broker-assisted workflows, and many such combinations of aspects of the above elements are contemplated.
Further details of aspects, objectives and advantages of the technological embodiments are described herein, and in the figures and claims.
The drawings described below are for illustration purposes only. The drawings are not intended to limit the scope of the present disclosure.
FIG. 3B1 shows a processing flow that implements event analysis and workflow triggering, according to some embodiments.
FIG. 3B2 exemplifies handling of an external processing request, according to some embodiments.
Aspects of the present disclosure solve problems associated with using computer systems for how to execute a workflow in multiple mutually-exclusive user contexts without copying the workflow into the multiple mutually-exclusive user contexts. These problems are unique to, and may have been created by, various computer-implemented methods for defining and enforcing file, folder read/write and execution permissions. Some embodiments are directed to approaches for forwarding a workflow trigger to a computer-implemented agent that executes the workflow on behalf of an initiating user.
Rather than copying a workflow to multiple user contexts, a broker module (e.g., a computer-implemented service agent) runs on behalf of a user while using a more permissive set of permissions (e.g., of an administrator). The service account has sufficient permissions to be able to access any of the aforementioned user contexts, yet can run as a proxy for the workflow triggering user. As such, the system emulates workflow cascading where one workflow triggers another workflow, and that workflow triggers yet another workflow, and so on.
Some of the terms used in this description are defined below for easy reference. The presented terms and their respective definitions are not rigidly restricted to these definitions—a term may be further defined by the term's use within this disclosure. The term “exemplary” is used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs. Rather, use of the word exemplary is intended to present concepts in a concrete fashion. As used in this application and the appended claims, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or”. That is, unless specified otherwise, or is clear from the context, “X employs A or B” is intended to mean any of the natural inclusive permutations. That is, if X employs A, X employs B, or X employs both A and B, then “X employs A or B” is satisfied under any of the foregoing instances. As used herein, at least one of A or B means at least one of A, or at least one of B, or at least one of both A and B. In other words, this phrase is disjunctive. The articles “a” and “an” as used in this application and the appended claims should generally be construed to mean “one or more” unless specified otherwise or is clear from the context to be directed to a singular form.
Various embodiments are described herein with reference to the figures. It should be noted that the figures are not necessarily drawn to scale, and that elements of similar structures or functions are sometimes represented by like reference characters throughout the figures. It should also be noted that the figures are only intended to facilitate the description of the disclosed embodiments—they are not representative of an exhaustive treatment of all possible embodiments, and they are not intended to impute any limitation as to the scope of the claims. In addition, an illustrated embodiment need not portray all aspects or advantages of usage in any particular environment.
An aspect or an advantage described in conjunction with a particular embodiment is not necessarily limited to that embodiment and can be practiced in any other embodiments even if not so illustrated. References throughout this specification to “some embodiments” or “other embodiments” refer to a particular feature, structure, material or characteristic described in connection with the embodiments as being included in at least one embodiment. Thus, the appearance of the phrases “in some embodiments” or “in other embodiments” in various places throughout this specification are not necessarily referring to the same embodiment or embodiments. The disclosed embodiments are not intended to be limiting of the claims.
As shown, the folder hierarchy is partitioned into multiple contexts, including an administrative context (e.g., first context 101) and two user contexts (e.g., second context 103 and third context 105). In one approach, a workflow object is initially stored in the administrator's context, and then copied into a user context when a user wants to invoke the workflow. However this approach unwantedly makes copies of the workflow object. Specifically, when there are a very large number of users, this creates the potential for a very large number of copies of the same workflow object.
Another approach is to have an administrator who has administrative privileges configure a workflow and store it in an administrative partition. When a user who does not have administrative privileges wants to execute the workflow in his or her context, then, using the herein-disclosed techniques, the user invokes a computer-implemented service agent. The computer-implemented service agent is granted broad privileges and can thus execute in the context of the user (e.g., accessing the user's files) while using permissions that are associated with the administrative partition (e.g., permissions to be able to access the single copy of the workflow object).
To illustrate, suppose that a folder hierarchy is organized such that a plurality of customer subhierarchies (e.g., a subfolder for ABC Corp 104, a subfolder for XYZ Corp 110, etc.) are hierarchically under a top-level folder (e.g., the folder for Customers 102). Further suppose that an admin defined a workflow and deposited the code and execution data of the workflow into the top-level folder (e.g., the folder for Customers 102). When a user (e.g., user1) who is scoped to ABC Corp (e.g., an employee of ABC Corp) or a when another user (e.g., user2) who is scoped to XYZ Corp (e.g., an employee of XYZ Corp) wants to run the workflow within their respective scopes, then the users might make unwanted copies into their respective scopes, and thereafter run the workflow. This technique of copying code and execution data of the workflow is strongly eschewed. Another technique that does not copy code and execution data of the workflow is strongly preferred. One such technique that does not copy code and execution data of the workflow to a user context, but nevertheless executes in the user's context is shown and described as pertains to
As used herein, a content management system is a computing system comprising executable code that facilitates performance of a set of coordinated functions, tasks, or activities on behalf of a plurality of collaborating users that operate over shared content objects. More specifically, a content management system facilitates collaboration activities such as creating a shared content object, establishing a set of users who can access the shared content object, concurrently (e.g., by multiple users at the same time) viewing a shared content object, concurrently editing a shared content object, modifying sharing configurations that pertain to a shared content object, and so on. In some embodiments such as are disclosed herein, a content management system is a computer system that captures events that are raised by users of the content management system and classifies certain of such events as workflow triggers.
When capturing the occurrence of workflow triggers, a content management system determines which user of the plurality of collaborating users raised the event, and then enforces access to shared content objects based on a set of permissions (e.g., access permissions) that correspond to the determined user. In some cases, the set of permissions that correspond to the determined user defines a user context. Such a user context may in turn correspond to the breadth and depth of a hierarchy of content objects. In some cases, and as used herein, a user context refers to those specific characteristics of a content management system that are associated with a user profile. Strictly as an example, a user context may refer to the metes and bounds of a hierarchy of folders of the content management system. In some cases, including in certain of the herein-disclosed embodiments, a user context may refer to the metes and bounds of a specific hierarchy of folders of the content management system, which specific hierarchy of folders corresponds to the metes and bounds and/or range of operation of a service agent.
The computer-implemented service 126 agent is configured with permissions to be able to operate in any hierarchy and in any user context. As such, the computer-implemented service agent can not only process a workflow triggering event within the triggering user's context (e.g., a workflow triggering event raised in user2's context), but can also traverse hierarchies. For example, if a workflow is triggered (e.g., by workflow initiator 127) in a lower level of hierarchy (e.g., “Customers/XYZ Corp/XYZ People”), then the computer-implemented service agent can traverse in any direction through the hierarchy in search of the location of workflows in any context that might be configured to execute based on the particular trigger.
Strictly as one example, consider a workflow that purges out-of-date versions of files. Such an operation might be useful by any customer; however, the actions taken by such a workflow would only be reasonable within that customer's context, and moreover, the actions taken by such a workflow might not be permitted across different areas of the hierarchy. More specifically, an execution of the aforementioned purging workflow that is triggered by user2 within user2's context 105 should only purge files from within user2's context (e.g., third context 105) and should not purge files from, for example, user1's context (e.g., second context 103). Such brokering behavior can be implemented by a computer-implemented service agent that is configured to execute in any given portion of the hierarchy and/or any given context.
To accommodate triggering of workflows, events raised by a user are forwarded to a computer-implemented service agent and analyzed to determine which workflow or workflows should be triggered by the forwarded triggering event. If it is determined that a local workflow should be initiated by the forwarded triggering event, then the local workflow is invoked. On the other hand, if the workflow or workflows that should be triggered are not found locally, then the folder hierarchy is traversed to find applicable workflows.
In various embodiments, such as the embodiment of 1B, the traversal can be carried out in whole or in part by one of more context-specific workflow managers (e.g., third context workflow manager 124THIRD, second context workflow manager 124SECOND, and first context workflow manager 124FIRST). One or more of the context-specific workflow managers may identify one or more workflows in its corresponding context, and the identified workflow or workflows are checked to see if the workflow or workflows are configured to be triggered by the particular forwarded triggering event.
When the computer-implemented service agent receives a workflow trigger from an event raised in a particular user context (e.g., in the context of a particular workflow initiator 127), the computer-implemented service agent executes in the particular user context while using administrative permissions. Execution of a first workflow in a first context might cause a new event that corresponds to a triggering event for a workflow that is to be executed in a second context. Any one or more of the context-specific workflow managers can execute continually so as to be able to receive incoming trigger events.
In the particular embodiment of 1B, each context has a corresponding context-specific workflow manager. Each of these context-specific workflow managers can run concurrently and can listen for triggering events that could at least potentially cause a workflow to be initiated. As such, through use of these context-specific workflow managers, the computer-implemented service agent can traverse freely throughout the hierarchy, possibly spanning multiple user and administrative contexts. As the computer-implemented service agent traverses the hierarchy, possibly with assistance from any one or more context-specific workflow managers (e.g., workflow manager 124FIRST, workflow manager 124SECOND, workflow manager 124THIRD, etc.) it looks for workflow objects (in any hierarchy) that can be analyzed to determine if a found workflow is to be executed based on the workflow trigger raised by the particular user. More particularly the computer-implemented service agent can: (1) look in any given folder hierarchy; (2) identify candidate workflow objects; (3) find and match candidate workflow objects against the particular workflow trigger; and (4) gather additional information as might be needed by the matched workflow. When gathering additional information that might be needed by the matched workflow, the computer-implemented service agent can access one or more third-party systems to enrich the trigger, and/or gather additional information associated with the found/matched workflows.
As used herein the terms “workflow” or “workflow objects” refers to any computer code that can be executed to carry out predefined actions. As examples, a workflow object may be a file that codifies a series of steps in an executable script language, and/or a workflow object may be a file that contains executable code. In some cases a workflow object is identified by merely (1) the existence of metadata in some location (e.g., in a folder) and/or, (2) a pointer to a file that contains executable script language, and/or, (3) by existence of a particular value of metadata and/or, (4) a pointer to a file that contains executable code. Any portion of, or entirety of, the series of steps codified in a workflow object and/or its subordinate files can be a candidate for being executed on behalf of (e.g., brokered for) a given user. Various techniques for implementing brokered workflows, including initial configuration/setup operations, are shown and described as pertains to
The figure is being presented to exemplify one possible technique for setting up an environment and then managing broker-assisted workflows on an ongoing basis. Specifically, the figure shows setup operations 201 that are performed in whole or in part prior to processing workflow triggers. The figure shows how an event 208 can be processed so as to invoke a broker or service agent that in turn executes a workflow on behalf of a user.
The terms broker or service agent are used interchangeably. Moreover, as used herein, a broker or service agent is computer code that can be executed in a context other than the particular context (e.g., user context, permissions context, hierarchical context, etc.) of the user that causes invocation of the computer code based on, or deriving from, the invoking user's actions. A workflow is a predefined series of steps and/or decisions that is invoked based on, or derived from, an action by a user. A broker-assisted workflow refers to all or portions of such a predefined series of steps and/or decisions, where the computer code is configured to be executed in a context other than the particular context of the invoking user. Such broker-assisted workflows and service agents can be established within a content management system (CMS), for example, by a series of setup operations.
Specifically, step 204 serves to configure a hierarchy of folders and files into various permission contexts. For example, a hierarchy of folders and file can be associated with a particular entity (e.g., a corporation) and that hierarchy, or portions thereof, can be configured for access by users who are associated with the particular entity. The hierarchy of folders may include subhierarchies. Moreover, any of the subhierarchies may be assigned to, or associated with, a particular grouping (e.g., a department or other organization) of users within the particular entity. Any hierarchy or subhierarchy, or grouping or department, or other organization may in turn be associated with respective permissions. In some cases, subhierarchies may be associated with different entities or boundaries (e.g., different corporations, different tenants, different geographies, etc.). In some of such cases, a first subhierarchy may be configured to be accessible by a first set of users, whereas a second subhierarchy may be configured to be accessible by a second set of users.
It might happen that a user of a workflow might not have sufficient privileges to be able to perform all of the actions of the workflow. To ameliorate this situation, an administrator who has administrative privileges might configure a computer-implemented service agent such that when a user who has only a limited set of privileges wants to execute the workflow in his or her context—and without needing to request additional privileges—then the computer-implemented service agent can be invoked to execute the workflow on behalf of the user. This can be facilitated by deploying the computer-implemented service agent (step 206) to be read-accessible by anyone, and by granting broad privileges (e.g., super-user privileges) to the computer-implemented service agent. In some embodiments the computer-implemented service agent is implemented as a script. In some embodiments the computer-implemented service agent is implemented as executable code. In some embodiments the computer-implemented service agent is implemented as a script or scripts and executable code in combination.
The thusly-configured computer-implemented service agent can be invoked at any point in time. In the specific example set of ongoing operations 203, the computer-implemented service agent is invoked based on an event raised by a workflow user 202, and further, based on an analysis of the event and/or any trigger parameters that are associated with the event. As shown, an event 208 may include and/or be associated with trigger parameters 212INITIAL. The event, plus any included and/or associated trigger parameters are received at a module that is specifically configured to listen for and respond to an incoming event that is at least potentially a workflow triggering event (step 210).
In some cases, an incoming event is not a workflow triggering event. In other cases, an incoming event is a workflow triggering event that pertains to a workflow that does not demand assistance from any computer-implemented service agent. In yet other cases, an incoming event is a workflow triggering event that pertains to a workflow that does, at least potentially, demand assistance from a computer-implemented service agent in order to access the workflow object and to then carry out the actions of the workflow. To address these latter two situations, step 211 serves to modify, augment (or pass) trigger parameters. Strictly as examples, trigger parameters might include designation of a workflow entry point, or the trigger parameters might include designation of some particular task that is to be scheduled concurrently with processing of any workflow or workflows that are invoked based on the incoming event.
After modifying and/or augmenting the trigger parameters (or passing-on unmodified trigger parameters), step 213 checks to see if the triggering event is associated with a workflow that is configured to be broker-assisted. The determination as to whether the triggering event is associated with a workflow that is configured to be broker-assisted can be made based on the event itself and/or based on the triggering parameters themselves. In some cases, the determination as to whether the triggering event is associated with a workflow that is configured to be broker-assisted can be made on the basis of results of a mapping operation (e.g., table row/column access operation, lookup query, data structure operation, etc.) that associates the event and/or the triggering parameters to a particular one or more workflows.
At decision 214, the results of the checks and/or mapping of step 210 are considered. If the checks and/or mapping of step 210 indicate that the event and/or the triggering parameters are to be forwarded to a service agent, then the “Yes” branch of decision 214 is taken. Otherwise, the “No” branch of decision 214 is taken, which in turn triggers the workflow (step 215).
Under conditions when the “Yes” branch of decision 214 is taken, the event (event 208) plus any event with trigger parameters are forwarded to the service agent (step 216). The service agent in turn invokes the workflow (step 218) on behalf of the workflow user (e.g., in the workflow user's hierarchical context), and executes the workflow in the permission context of the service agent. At any point in time, possibly at multiple points in time after invocation of the workflow, step 220 serves to provide workflow execution status to the workflow user.
As depicted, ongoing operations 203 can be carried out continually. Moreover, any number of asynchronously operating sets of ongoing operations can be carried out concurrently. As such, any number of workflows as invoked by any number of workflow users can execute at the same time.
The figure is being presented to show one embodiment of certain representative components and associated data structures and data flows that are implemented in a client-server computing environment. As shown, the components, data flows, and data structures are associated with a set of users that interact with each other (e.g., user 3011, . . . , user 301N) and a set of content objects 306 managed at a content management system 308. The components, data flows, and data structures shown in
As shown, system 3A00 comprises an instance of content management server 310 operating at content management system 308. Content management server 310 comprises a message processor 312 and an instance of a workflow manager 124, which comprises a workflow mapping service 314, a workflow configurator 316, a workflow state monitor 318, and a state publisher 320. A plurality of instances of the foregoing components might operate as concurrently-running instances across a plurality of instances of content management servers of content management system 308. Such instances can interact with communications layer 322 to access each other and/or a set of storage devices 330 that store various information to support the operation of components of system 3A00 and/or any implementations of the herein disclosed techniques.
For example, the servers and/or storage devices of content management system 308 might facilitate interactions over content objects 306 by the users (e.g., user 3011, . . . , user 301N) from a respective set of user devices (e.g., user device 3021, . . . , user device 302N). A content management system manages a plurality of content objects at least in part by maintaining (e.g., storing, updating, resolving interaction conflicts, etc.) the content objects subject to the various interactions performed over the content objects by users of the content objects at their respective user devices. The content objects (e.g., files, folders, etc.) in content objects 306 are characterized at least in part by a set of object attributes 340 (e.g., content object metadata) stored at storage devices 330. Furthermore, the users may be characterized, at least in part, by a set of user attributes 341 that are stored in user profiles 332.
Further details regarding general approaches to handling object attributes including content object metadata are described in U.S. application Ser. No. 16/553,144 titled “EXTENSIBLE CONTENT OBJECT METADATA”, filed on Aug. 27, 2019, which is hereby incorporated by reference in its entirety.
The users access instances of applications at their respective user devices so as to interact with content objects 306 that are managed by content management system 308. As shown, the applications can comprise instances of native applications or instances of third-party applications (e.g., application 110F, which might be a Facebook or “F” application or application 110s, which might be a Sign-Request or “S” application, etc.). Various information pertaining to integration of such applications with content management system 308 may be codified in workflow registry 336. At least some items of workflow registry 336 comprises instances of workflow-specific information 346. In some cases, certain portions of the information in workflow registry 336 might be locally accessible at the user devices by the applications. For example, a first workflow registry might be accessible by application 110F and/or other applications at user device 3021, while a second workflow registry at the CMS might be accessible via a CMS interface (e.g., CMS interface 3041, . . . , CMS interface 304N) and/or by any other module of the user device.
The instances of the applications operating at the user devices send or receive various instances of messages 324 that are received or sent by message processor 312 at content management server 310. In some cases, messages 324 are sent to or received from content management server 310 without human interaction. One class of messages 324 corresponds to workflow-specific information received at content management system 308 in response to executing an application. For example, instances of workflow-specific information 346 that correspond to a particular workflow might be issued by an enterprise and stored in workflow registry 336 (e.g., such as when the workflow is registered with content management system 308.
According to the herein disclosed techniques, when users interact with content objects 306 at applications operating on the user device, application requests are issued as instances of messages 324 to content management system 308. In some situations, the application requests are issued to the system specifically to invoke one or more workflows that are associated in some way with the running application and/or the user's environment and/or associated in some way with one or more of the content objects. Message processor 312 receives the application's requests and forwards them to workflow mapping service 314. The workflow mapping service 314 in turn accesses application-specific information 346, and/or object attributes 340, and/or other information to select workflows that are associated with the respective application requests.
A workflow configurator 316 might configure a particular instance of a workflow in the form of API calls that indicate any one or more of: a workflow type, a subject content object, and/or other information.
Another class of messages 324 corresponds to interaction events that occur during the course of workflow execution at the applications. Interaction events might include activities such as creating, viewing, modifying, or deleting content objects. When such interaction events occur, the mechanisms (e.g., API communications, etc.) established when integrating the applications with content management system 308 are accessed to issue interaction event messages to workflow state monitor 318 through message processor 312. Sets of event attributes 345 that correspond to the interaction events and/or corresponding interaction event messages are stored in event records 334 at storage devices 330. State publisher 320 accesses such event attributes in event records 334 to generate activity updates that are published to various applications at the user devices (e.g., when a workflow changes state and/or when a workflow is deemed to be complete). As merely one example, when a workflow is invoked from application 110F, that event is recorded in event records 334 and an activity update is pushed to application 110F.
The foregoing system is sufficiently configured to be able to implement event analyses and workflow triggering events in a variety of scenarios. One possible implementation of event analysis and workflow triggering is shown and described as pertains to FIG. 3B1 and FIG. 3B2.
FIG. 3B1 shows a processing flow that implements event analysis and workflow triggering. As an option, one or more variations of the processing flow or any aspect thereof may be implemented in the context of the architecture and functionality of the embodiments described herein. The shown techniques or any aspects thereof may be implemented in any environment.
This figure is being presented to illustrate one possible processing flow for performing event analysis and workflow triggering. In particular, the shown processing flow can implement a wide variety of use cases, any/all of which can be concurrently operable in the CMS as heretofore described.
The processing flow of FIG. 3B1 commences upon receipt of an event 208. The event might or might not be an event that is, or should, or could cause a workflow to be invoked. Accordingly, the operations of module 342 serve to analyze the event for applicability to a workflow. In particular, operations of module 342 access the workflow registry 336 to retrieve event metadata 350 as well as workflow metadata 348. On the basis of consideration of the event metadata and the workflow metadata, which can be considered either singly or in combination, a determination is made at decision 344 whether or not the event is a workflow triggering event. When the event is not a workflow triggering event, then the processing flow can take the “No” branch of decision 344 and returns to the caller. On the other hand, when the event is determined to be a workflow triggering event, then the “Yes” branch of decision 344 is taken and the event is further processed.
Various forms of event processing 360 can be undertaken to determine if there are any workflows in the current folder or if there are any workflows in other folders of the hierarchy. Such determinations can be made by the shown step 352 to determine if a workflow that corresponds to the triggering event is present in the current folder. Similarly, determinations can be made by the shown step 356 to determine if a workflow that corresponds to the triggering event is present in other locations (e.g., in ancestors of the current folder, or in children of the current folder).
As shown, there can be many triggering event types 354, any of which may correspond to an event to upload a file or folder, or to download a file or folder, or to move a file or folder, or to signify task completion, or to signify task rejection, etc. The foregoing triggering event types are merely examples and in this embodiment, irrespective of the particular triggering event, when a workflow corresponding to the triggering event is found (determination 362), the event (e.g., event 208) plus any information that might be taken from or derived from information in the workflow registry is made available to step 363.
In this embodiment, step 363 populates a set of trigger parameters, possibly based on the incoming event, and/or possibly based on any information that might be taken from or derived from information in the workflow registry. For example, data that informs the trigger parameters might be drawn from metadata of the CMS. In some cases, the particular data that informs the trigger parameters might augment or otherwise modify the initially-received trigger parameters 212INITIAL to create trigger parameters 212UPDATED. In some cases, the created trigger parameters 212UPDATED includes trigger parameters that were not included in the received trigger parameters 212INITIAL. In some cases, the created trigger parameters 212UPDATED includes trigger parameters or trigger parameter values that have been updated since initial generation of the received trigger parameters 212INITIAL.
The populated trigger parameters are passed to module 364, which in turn forwards populated instances of trigger parameters 212UPDATED and/or event 208 to a service agent which in turn will invoke the found workflow(s).
Execution of the found workflow(s) and/or execution of any cascaded workflow(s) may result in a need for additional information that is used in further processing of the workflow. One possible technique for obtaining additional information is shown and described as pertains to FIG. 3B2.
FIG. 3B2 exemplifies handling of an external processing request 365. The external processing request can be satisfied by accessing information that is outside the bounds of the CMS, but nevertheless accessible, directly or indirectly, by the CMS. In some situations the external processing request demands information that is a under the control of a third-party. In such cases, and as shown, step 366 serves to access third-party facility 369 to gather the requested information.
In some cases, the third-party facility hosts a workflow object 305 that in turn can be triggered to gather the requested information. A third-party facility may be a system that is accessible to the CMS over a network, or a third-party system can be implemented as an executable module within the CMS.
Further details regarding general approaches to accessing third-party workflows are described in U.S. application Ser. No. 16/726,093 titled “EXTENSIBLE WORKFLOW ACCESS” filed on Dec. 23, 2019, which is hereby incorporated by reference in its entirety.
The requested and gathered information and/or any changes to any information that occurs as a consequence of, or in response to, execution of one or more workflows at the third-party facility may result in updated workflow parameters 367, as shown. More particularly the updated workflow parameters may be provided to the particular workflow that raised the external processing request, or the updated workflow parameters may be provided to a particular service agent.
Now, returning to the discussion of FIG. 3B1, and in particular referring to discussion of module 342 to analyze an incoming event, it has been previously discussed that events may correspond to actions taken in the CMS that triggers invocation of one or more workflows. Alternatively or additionally, certain events may correspond to actions taken in or by the CMS that are specific to third-party systems. Still further, certain events may correspond to actions taken in or by the CMS that are specific to obtaining e-signatures and/or are specific to obtaining other forms of authorizations. These actions as well as other actions can be raised during the course of event analysis. Some examples are shown and discussed as pertains to
The figure is being presented to offer a sampling of actions that can be raised during the course of event analysis. The particular events and their corresponding actions that are discussed below are merely examples; other event types and other action types are contemplated.
As shown, the flow of
With respect to expiration of timer events, the shown flow supports a variety of scheduled events, which scheduled events may correspond to actions (e.g., workflow actions) that are to be taken on a periodic basis. Strictly as an illustration, a timer can be configured to emit a workflow-initiating event periodically such that the workflow or workflows corresponding to that event is invoked. In one example, a timer can be configured to periodically (e.g., daily) emit an event that invokes a “purge” workflow, where the “purge” workflow moves outdated files from a particular folder or hierarchy to another location for long-term storage. As another example, a timer can be configured to periodically (e.g., hourly) emit an event that invokes an “auto-collab” workflow, where the “auto-collab” workflow automatically adds (e.g., collabs-in) a batch of new employees to a selection of folders that correspond to the roles and responsibilities of the new employees. As yet another example, a timer can be configured to periodically (e.g., daily) emit an event that invokes a “vendor onboard” workflow, where the “vendor onboard” workflow automatically adds a new vendor to a vendor database. The information that is added to the vendor database can derive from any user—including users who do not have access to the vendor database. This is because a service agent is used to broker the activities of adding the vendor entry into the database on behalf of the requesting user.
The foregoing examples rely, at least in part, on the ability of a user to raise an event from any context. The raised event can be analyzed locally, or the raised event can be forwarded to a module that in turn analyzes the event to determine one or more next actions.
Specifically, a particular received event can be analyzed to determine if the event corresponds to any of a variety of use models. In this illustrative embodiment, test 404 serves to determine if the incoming event corresponds to a group-wide task or group-wide workflow. For example, certain authorizations (e.g., a purchase requisition (PR) authorization) are often intended to be handled by any one from among a particular group (e.g., by any member of the “Purchasing” organization). Accordingly, in such a case, a workflow task (e.g., a task to review the PR and initiate a ‘PR authorization’ workflow) can be assigned to all members of the “Purchasing” organization.
Similarly, and strictly as an example, a workflow task (e.g., a task for company attorneys to review a non-disclosure agreement) can be assigned to all attorneys of the “Legal” team, and any one of the attorneys can perform the task. In some situations, a single task may be applied to multiple files. For example, the provision of the workflow task, “Review these non-disclosure agreements” might refer to a group or bundle of non-disclosure agreements, each non-disclosure agreement pertaining to a different party. Such a task can be deemed to have been completed once all of the non-disclosure agreements of the group or bundle have been reviewed or, such a task can be deemed to have been completed each time a particular one the non-disclosure agreements of the group or bundle have been reviewed. Completion of a workflow task can trigger additional workflows.
If it is determined that the incoming event corresponds to a group-wide task or group-wide workflow, then the “Yes” branch of decision 404 is taken and step 406 serves to determine the members of any one or more particular groups (e.g., constituents/employees who are members of the “Purchasing” organization) and assign the workflow tasks to each members.
In a different scenario, test 408 determines if the incoming event is an event that corresponds to a third-party file request. If so, the “Yes” branch of test 408 is taken and step 410 serves to gather information corresponding to the particular third-party file request. The term “third-party file request” refers to operations and/or exchanges between the CMS and a different service provider, where the operations and/or exchanges result in a file or file contents or related metadata being exchanged between the CMS and the different service provider. In some cases, aspects of a file or file contents or related metadata serve to inform and/or steer processing of workflows. In some cases the related metadata is stored in a persistent location such that that related metadata can be used to inform triggers as may pertain to subsequent workflow processing.
In one scenario, returned information from a third-party file request might include a dollar amount that corresponds to a “contract value”. That dollar amount may then be used to route subsequent workflow actions to an account leader or administrator for further processing. More specifically, the particular dollar amount that corresponds to a “contract value” might inform which particular groups or employees should be the recipients of subsequent workflow tasks.
In a different scenario, test 412 determines if the incoming event is an event that corresponds to a signature request. If so, the “Yes” branch of test 412 is taken and step 414 serves to schedule one or more signature requests. Strictly as one example, a signature request (e.g., an authorization) might be tied to a particular document or document type (e.g., a purchase order). In some cases, multiple signature requests are schedule for the same document. In some cases, the determination of who needs to sign (e.g., authorize) the document is based on contents of the subject document.
Further details regarding general approaches to making and using electronic signatures in a CMS are described in U.S. application Ser. No. 17/376,110 titled “ACQUIRING ELECTRONIC-BASED SIGNATURES” filed on Jul. 14, 2021, which is hereby incorporated by reference in its entirety.
While
The figure is being presented to illustrate how information that pertains to workflows and their corresponding trigger parameters can be gathered. Moreover, the figure is being presented to illustrate how the gathered information, together with information pertaining to the workflow-initiating user, can be cast into a form that can in turn be used to invoke a service agent that executes the workflow on behalf of a particular workflow-initiating user.
As shown, the workflow triggering techniques are presented as two processing flows. The top flow is an example implementation of step 363 of FIG. 3B1 and the bottom flow is an example implementation of module 364 of FIG. 3B1. More specifically, the top flow implements a technique to determine workflow trigger parameters and the bottom flow implements a technique to invoke a service agent that executes a particular workflow with the determined workflow trigger parameters.
The top flow commences when it has been determined that one or more workflows are to be performed on the basis of an incoming event (e.g., the shown event 208). Upon such an occurrence, step 416 commences to gather triggering information. Such triggering information may be present in a workflow registry 336. In some cases, the workflow registry contains a mapping table such as is depicted by Table 1.
In sequence or in parallel, further operations are performed to gather triggering information (step 418). Based on the gathered triggering information and/or the gathered workflow information, a set of triggerable workflows is identified (step 420). In some cases, there are multiple workflows that are to be triggered. As such, a FOREACH loop is entered to handle each workflow individually. Specifically, and as shown, step 422 serves to cast the event and any other gathered information onto a trigger for a particular workflow. In exemplary iterations through this FOREACH loop, a particular service agent (pertaining to this FOREACH loop iteration) is invoked to execute the particular workflow (pertaining to this FOREACH loop iteration) on behalf of the particular user. In such cases, step 423 serves to gather information about the workflow initiator. Characteristics of the event and/or trigger information, and/or information about the user are made available to the service agent that will be invoked (step 424) to perform a workflow (pertaining to this FOREACH loop iteration) on behalf of the user. The FOREACH loop ends when there are no more workflows to be iterated over.
As can be seen from the foregoing discussion of
As previously mentioned as pertaining to some embodiments, workflows can be stored in any portion of any hierarchy of files and folders of the CMS. As such, some means needs to be provided to facilitate identification of a workflow regardless of their location within files and folders of the CMS. More particularly, some means needs to be provided to facilitate traversal of files and folders of the CMS by a service agent. To do so, a service agent might be granted an appropriate set of privileges. For example, a service agent can be granted a set of privileges that correspond to super user privileges. As such, the service agent can traverse files and folders of the CMS at least to be able to read the contents of folders and/or directories.
The heavy arrow annotations shown in the folder hierarchy 5A00 illustrate how super user privileges for the service agent facilitates traversal of files and folders of the CMS so as to read the contents of folders and/or directories regardless of their position in the folder hierarchy (e.g., regardless of any ALLOW/DENY permissions set on the files and folders). As such, workflow objects in any file or folder can be identified, read, and executed by the service agent.
To illustrate, consider the situation where workflow initiator 127 (e.g., user user2) raises event event1 in or at or pertaining to the folder showing as internal 516. It might be that event1 is an event that should cause invocation of a workflow. In this case, identification of a particular one or more workflows commences by first examining, via a super user service agent, the folder showing as “Internal” 516. If there is a workflow object in the folder showing as “Internal” 516, then that workflow becomes a candidate for invocation. However, if there is not a workflow object in the folder showing as “Internal” 516, then the super user service agent can traverse upwards in the hierarchy to examine the contents of the hierarchically higher folder showing as “Marketing” 510. If there is not a workflow object in the folder showing as “Marketing” 510, then the super user service agent can traverse upwards in the hierarchy to examine the contents of the hierarchically higher folder showing as “HR” 504. Even when there is not a workflow object in the folder showing as “HR” 504, the super user service agent can examine the folder to check if there exists metadata (e.g., metadata that refers to a workflow object, or metadata that hold some particular value or values, etc.) or a directory of workflows. In this example, there is a directory, specifically, directory 503HR. The directory can be consulted by a super user service agent. The directory may indicate locations of workflow objects. In the shown example, directory 503HR does indeed indicate a location of workflow object 505 (in the folder showing as “Published” 508). Accordingly, that workflow object can become a candidate workflow to be invoked, subject to the semantics of event event1 and subject to other conditions as may be present in the CMS and/or in third-party systems.
The foregoing is merely one example to illustrate a possible technique for identifying a workflow object. However, many other techniques are possible. Strictly as one example of other possible techniques, it might happen that a folder is associated with particular metadata or particular metadata values. Detection of existence of particular metadata or particular metadata values can happen when traversing through a hierarchy during the course of examining the contents of folders in the hierarchy. To illustrate, a brokered workflow might be scheduled to perform consistency checks on folders that contain or are associated with the metadata tag=“SECRET”. Similarly, a brokered workflow might be scheduled to perform consistency checks on folders that contain or are associated with the metadata tag “SECURITY LEVEL”, but only if/when the metadata tag “SECURITY LEVEL” has the metadata tag value=“SECRET”. In some cases a brokered workflow might be scheduled on the basis that a particular metadata tag is absent from, or otherwise not associated with, a folder. In some cases a workflow template informs the scope of metadata tags and/or values of interest when traversing through a hierarchy during the course of examining the contents of folders in the hierarchy.
Further extents of the files of folders of the CMS can be traversed. Even though, as pertains to the foregoing examples, an initial candidate workflow had been identified, the super user service agent can traverse other portions of the hierarchy of content objects (e.g., folders and/or files, and/or metadata) to examine further folders, and/or the contents of such further encountered folders. In some cases, the contents of encountered folders (e.g., folder “ABC Corp” 502) may have still further directories (e.g., “Directory” 503CORP), any of which can refer to still further workflow objects that might at least be candidates for invocation based on the event event1 raised by user user2.
The foregoing discussion of example folder hierarchy 5A00 is merely one illustrative example. Alternative use models are possible.
The figure is being presented to illustrate in a step-by-step manner of how a CMS system that has a file and folder hierarchy such a depicted in
The illustrative example operates within a CMS that has been configured (step 522) to have three different users with three different access permission sets. Such a configuration further establishes a file and folder hierarchy having three or more different user contexts (step 524). A workflow creator (e.g., the user shown as super user 509) establishes a workflow object in a first one of the three or more different user contexts. In this case, the workflow creator and has permissions of a super user.
A listener in the CMS identifies a workflow triggering event based on an action taken by a workflow initiator 127 (e.g., the user shown as user2) within a second one of the three or more different user contexts (step 526). Upon receipt of a trigger (e.g., trigger 527USER2CONTEXT) a service agent, on behalf of the second user, performs a workflow of the first context, but within the context of the second user (step 528). The service agent does so by availing of permissions of the super user. During execution of the particular workflow of the first context a listener in the CMS identifies a further workflow triggering event (step 530) based on execution of the particular workflow by the super user. The further triggered workflow might exist in a different context, and as such, a context switch occurs. Based on the further trigger (e.g., trigger 527USER3CONTEXT) an instance of a service agent performs the further triggered workflow in the third context using permissions of the super user (step 532).
In another use case, a workflow is built by an arbitrary workflow creator using workflow templates. This use case is shown and described as pertains to
The figure is being presented to illustrate use cases where a user, using a workflow builder, can create and publish a workflow for use by anyone, even though different users are assigned into mutually exclusive access portions of the CMS file and folder hierarchy. To set this up, and as shown, an administrator (e.g., a CMS administrator) establishes a file and folder hierarchy having two or more mutually exclusive access portions (step 552). The two or more mutually exclusive access portions may correspond to different entities (e.g., different corporations, different tenants, different departments, etc.). Two or more different sets of users are associated with the different entities, which in turn means that two or more different sets of users are associated with the two or more mutually exclusive access portions. A user of a first mutually exclusive access portion (e.g., a user associated with a first department of a company) might define a workflow that is useful for all users (e.g., users associated with a second department of a company, etc.). For example, the HR department might define a workflow that can be useful for all employees to update their respective HR profiles. In this scenario, the HR profiles are stored in an exclusive access portion of the CMS—the HR profiles are not accessible to users who are associated with different mutually exclusive access portions (step 554). This presents a potential problem that can be solved by using the herein-disclosed techniques.
Continuing this example, an “HR Profile Upload” workflow can be created and then stored in the HR portion of the CMS file and folder hierarchy. That “HR Profile Upload” workflow can be associated with a service agent, and then published such that users from outside the HR access portion can nevertheless avail themselves to the operations of the “HR Profile Upload” workflow. That is, when a user from outside the HR department attempts to upload an update to the HR profiles, a corresponding event can be propagated to an instance of a service agent. Alternatively, a user who is associated with a mutually exclusive access portion other than the HR department's access portion can attempt to upload a file (e.g., upload to the HR profiles folder of the HR department). Upon the event of such an attempt, and upon mapping that event and/or its corresponding triggering parameters to the “HR Profile Upload” workflow, the workflow can be executed using super user privileges. The shown process flow of
As shown, a workflow creator 507 uses a workflow object builder 523, which in turn may use workflow templates 525. A workflow object builder can present a graphical user interface that facilitates definition of a workflow, possibly by presenting user-selectable and/or user-specifiable options that refer to conditions or events that would trigger a particular workflow, and/or actions to be taken whenever the conditions or events are detected.
At step 556, the workflow creator (or an administrator) can enable access by HR department users to be able to perform file and folder operations over the HR department subhierarchy (e.g., the first one of the mutually exclusive access portions). A workflow object is created, and the workflow creator can store a workflow object in a first one of the mutually exclusive access portions. When a second user (e.g., user2) ‘attempts’ to upload a file to the HR profiles folder of the HR department (step 558), then upon detection of that event (e.g., second user's event 559) the workflow is performed on behalf of the second user by an invoking service agent that has super user privileges (step 560).
The foregoing scenario involved but one illustrative use case, one type of event, and one type of automated action; however other use cases, other types of events, and other types of automated action are contemplated. A selection of use cases (Table 2) and a selection of automated actions (Table 3) are presented hereunder.
Embodiments of the herein-disclosed techniques can be implemented in various computing architectures. An example of one such architecture is presented hereunder.
According to an embodiment of the disclosure, computer system 6A00 performs specific operations by data processor 607 executing one or more sequences of one or more program instructions contained in a memory. Such instructions (e.g., program instructions 6021, program instructions 6022, program instructions 6023, etc.) can be contained in or can be read into a storage location or memory from any computer readable/usable storage medium such as a static storage device or a disk drive. The sequences can be organized to be accessed by one or more processing entities configured to execute a single process or configured to execute multiple concurrent processes to perform work. A processing entity can be hardware-based (e.g., involving one or more cores) or software-based, and/or can be formed using a combination of hardware and software that implements logic, and/or can carry out computations and/or processing steps using one or more processes and/or one or more tasks and/or one or more threads or any combination thereof.
According to an embodiment of the disclosure, computer system 6A00 performs specific networking operations using one or more instances of communications interface 614. Instances of communications interface 614 may comprise one or more networking ports that are configurable (e.g., pertaining to speed, protocol, physical layer characteristics, media access characteristics, etc.) and any particular instance of communications interface 614 or port thereto can be configured differently from any other particular instance. Portions of a communication protocol can be carried out in whole or in part by any instance of communications interface 614, and data (e.g., packets, data structures, bit fields, etc.) can be positioned in storage locations within communications interface 614, or within system memory, and such data can be accessed (e.g., using random access addressing, or using direct memory access DMA, etc.) by devices such as data processor 607.
Communications link 615 can be configured to transmit (e.g., send, receive, signal, etc.) any types of communications packets (e.g., communication packet 6381, communication packet 638N) comprising any organization of data items. The data items can comprise a payload data area 637, a destination address 636 (e.g., a destination IP address), a source address 635 (e.g., a source IP address), and can include various encodings or formatting of bit fields to populate packet characteristics 634. In some cases, the packet characteristics include a version identifier, a packet or payload length, a traffic class, a flow label, etc. In some cases, payload data area 637 comprises a data structure that is encoded and/or formatted to fit into byte or word boundaries of the packet.
In some embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement aspects of the disclosure. Thus, embodiments of the disclosure are not limited to any specific combination of hardware circuitry and/or software. In embodiments, the term “logic” shall mean any combination of software or hardware that is used to implement all or part of the disclosure.
The term “computer readable medium” or “computer usable medium” as used herein refers to any medium that participates in providing instructions to data processor 607 for execution. Such a medium may take many forms including, but not limited to, non-volatile media and volatile media. Non-volatile media includes, for example, optical or magnetic disks such as disk drives or tape drives. Volatile media includes dynamic memory such as RAM.
Common forms of computer readable media include, for example, floppy disk, flexible disk, hard disk, magnetic tape, or any other magnetic medium; CD-ROM or any other optical medium; punch cards, paper tape, or any other physical medium with patterns of holes; RAM, PROM, EPROM, FLASH-EPROM, or any other memory chip or cartridge, or any other non-transitory computer readable medium. Such data can be stored, for example, in any form of external data repository 631, which in turn can be formatted into any one or more storage areas, and which can comprise parameterized storage 639 accessible by a key (e.g., filename, table name, block address, offset address, etc.).
Execution of the sequences of instructions to practice certain embodiments of the disclosure are performed by a single instance of a computer system 6A00. According to certain embodiments of the disclosure, two or more instances of computer system 6A00 coupled by a communications link 615 (e.g., LAN, public switched telephone network, or wireless network) may perform the sequence of instructions required to practice embodiments of the disclosure using two or more instances of components of computer system 6A00.
Computer system 6A00 may transmit and receive messages such as data and/or instructions organized into a data structure (e.g., communications packets). The data structure can include program instructions (e.g., application code 603), communicated through communications link 615 and communications interface 614. Received program instructions may be executed by data processor 607 as it is received and/or stored in the shown storage device or in or upon any other non-volatile storage for later execution. Computer system 6A00 may communicate through a data interface 633 to a database 632 on an external data repository 631. Data items in a database can be accessed using a primary key (e.g., a relational database primary key).
Processing element partition 601 is merely one sample partition. Other partitions can include multiple data processors, and/or multiple communications interfaces, and/or multiple storage devices, etc. within a partition. For example, a partition can bound a multi-core processor (e.g., possibly including embedded or co-located memory), or a partition can bound a computing cluster having plurality of computing elements, any of which computing elements are connected directly or indirectly to a communications link. A first partition can be configured to communicate to a second partition. A particular first partition and particular second partition can be congruent (e.g., in a processing element array) or can be different (e.g., comprising disjoint sets of components).
A module as used herein can be implemented using any mix of any portions of the system memory and any extent of hard-wired circuitry including hard-wired circuitry embodied as a data processor 607. Some embodiments include one or more special-purpose hardware components (e.g., power control, logic, sensors, transducers, etc.). Some embodiments of a module include instructions that are stored in a memory for execution so as to facilitate operational and/or performance characteristics pertaining to implementing broker-assisted workflows. A module may include one or more state machines and/or combinational logic used to implement or facilitate the operational and/or performance characteristics pertaining to implementing broker-assisted workflows.
Various implementations of database 632 comprise storage media organized to hold a series of records or files such that individual records or files are accessed using a name or key (e.g., a primary key or a combination of keys and/or query clauses). Such files or records can be organized into one or more data structures (e.g., data structures used to implement or facilitate aspects of broker-assisted workflows). Such files, records, or data structures can be brought into and/or stored in volatile or non-volatile memory. More specifically, the occurrence and organization of the foregoing files, records, and data structures improve the way that the computer stores and retrieves data in memory, for example, to improve the way data is accessed when the computer is performing operations pertaining to processing broker-assisted workflows, and/or for improving the way data is manipulated when performing computerized operations pertaining to forwarding a workflow trigger to a computer-implemented agent that executes the workflow on behalf of the initiator.
A portion of workspace access code can reside in and be executed on any access device. Any portion of the workspace access code can reside in and be executed on any computing platform 651, including in a middleware setting. As shown, a portion of the workspace access code resides in and can be executed on one or more processing elements (e.g., processing element 6051). The workspace access code can interface with storage devices such as networked storage 655. Storage of workspaces and/or any constituent files or objects, and/or any other code or scripts or data can be stored in any one or more storage partitions (e.g., storage partition 6041). In some environments, a processing element includes forms of storage, such as RAM and/or ROM and/or FLASH, and/or other forms of volatile and non-volatile storage.
A stored workspace can be populated via an upload (e.g., an upload from an access device to a processing element over an upload network path 657). A stored workspace can be delivered to a particular user and/or shared with other particular users via a download (e.g., a download from a processing element to an access device over a download network path 659).
In the foregoing specification, the disclosure has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the disclosure. For example, the above-described process flows are described with reference to a particular ordering of process actions. However, the ordering of many of the described process actions may be changed without affecting the scope or operation of the disclosure. The specification and drawings are to be regarded in an illustrative sense rather than in a restrictive sense.
The present application claims the benefit of priority to U.S. Provisional Patent Application Ser. No. 62/706,866 titled “SCALABLE WORKFLOWS” filed on Sep. 14, 2020, which is hereby incorporated by reference in its entirety; and present application claims the benefit of priority to U.S. Provisional Patent Application Ser. No. 62/706,863 titled “EXECUTION STATE WORKFLOW VARIABLES” filed on Sep. 14, 2020, which is hereby incorporated by reference in its entirety; and the present application claims the benefit of priority to U.S. Provisional Patent Application Ser. No. 62/706,862 titled “CASCADED WORKFLOWS” filed on Sep. 14, 2020, which is hereby incorporated by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 62706866 | Sep 2020 | US | |
| 62706863 | Sep 2020 | US | |
| 62706862 | Sep 2020 | US |
