Patent Application
20250231821
Workflow management may include identifying, categorizing, structuring, tracking, documenting, or optimizing various tasks and processes. In some circumstances, a workflow management system provides an infrastructure for the set-up, performance, and monitoring of a defined sequence of tasks.
Correctly applied, workflow management brings together clear visibility, process automation, and support tools to guide people and processes. Additionally, teams that operate within reliable workflows see greater productivity and efficiency, and are more goal-oriented than those who do not. However, some workflow management systems do not provide efficient or effective access to workflow data, and therefore these systems do not allow for effective visibility into the steps and processes involved and which roles are responsible for which actions.
Various embodiments of the invention are disclosed in the following detailed description and the accompanying drawings.
The invention can be implemented in numerous ways, including as a process; an apparatus; a system; a composition of matter; a computer program product embodied on a computer readable storage medium; and/or a processor, such as a processor configured to execute instructions stored on and/or provided by a memory coupled to the processor. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the invention. Unless stated otherwise, a component such as a processor or a memory described as being configured to perform a task may be implemented as a general component that is temporarily configured to perform the task at a given time or a specific component that is manufactured to perform the task. As used herein, the term ‘processor’ refers to one or more devices, circuits, and/or processing cores configured to process data, such as computer program instructions.
A detailed description of one or more embodiments of the invention is provided below along with accompanying figures that illustrate the principles of the invention. The invention is described in connection with such embodiments, but the invention is not limited to any embodiment. The scope of the invention is limited only by the claims and the invention encompasses numerous alternatives, modifications and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the invention. These details are provided for the purpose of example and the invention may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the invention is not unnecessarily obscured.
The fundamental units of work are tasks, processes, and workflows. A task is the basic building block of all work. Tasks are performed by individuals, but they can vary dramatically in complexity and time required for completion. Tasks may be divided into two types: single step and multi-step. When tasks are grouped together to achieve a desired result or objective, they form a process. For example, when an employee needs help solving an information technology (IT) issue, the employee initiates a process made up of multiple tasks. Processes that become interdependent with other people or processes are called workflows. A workflow comprises the interdependent processes and people required to reach a result that no single participant can achieve alone.
For example, submitting a help-desk request to IT is one element of a larger workflow that ultimately resolves the issue. Processes contained in the IT department are set in motion by requests, leading to prioritization, assignment, and fulfillment. The span of activities from problem to solution, and every person involved, comprises a workflow. The help-desk ticket workflow example may include a number of processes. During the first process, the employee with the broken equipment submits and tracks a help ticket. During the second process, Help Staff prioritizes and investigates the help ticket. During the third process, a technician visits the employee to see the problem in person. A process may include multiple tasks. For example, during the third process, the visit from a technician involves assigning the problem, determining the employee's location, and confirming that it is a good time for a visit, etc.
A cloud-based workflow management and automation tool may be used to allow users to design, build, and manage automated processes and workflows. There are a number of benefits that can be gained by using such a system, including improved efficiency, improved accuracy, better visibility, improved customer service, and the like.
For example, a workflow management and automation tool may provide step-by-step guidance for resolving processes and enable agents to easily manage the lifecycle of cases by guiding them through sequences of tasks. The workflows that are associated with a specific type of case and the activities that need to be completed to resolve cases of this type are detailed in the tool. The tool may also include a graphical user interface (UI) that helps users to visualize the entire lifecycle of a workflow.
However, existing workflow management and automation tools have different limitations and inefficiencies. Traditional techniques do not have consistent ways for handling data flows through the workflow management and automation tool, updating the UIs, and storing persistent data to the database. The workflow management and automation tool may provide a number of different UIs/views, including a board view and a diagram view. For example, a visual task board or Kanban board view provides a visual representation of work items, organized into columns that represent different stages of the workflow. The board may be divided into swimlanes, which may represent different teams, projects, or work types. A diagram view or a process diagram provides a visual representation of the flow and dependencies within a process or system. When a user makes changes to a process in one view, the different views sharing the same data should be updated to reflect the changes made to the process. For example, when the user adds an activity to a process, both the board view and the diagram view should be updated. Each view may have different requirements. In other traditional techniques, after an operation is made in one view, the change of the data associated with the operation is stored in a database, and other views will need to re-fetch the information from the database in order to update all the views to reflect those changes. In other words, the database is used as the single source of truth. In a single source of truth (SSOT) architecture, information models and associated data schemas are structured such that every data element is mastered (or edited) in only one centralized location.
However, using the database as the single source of truth has a number of disadvantages. An operation (e.g., adding an activity or deleting an activity in a process) in a particular view may not always map directly onto a database operation. Each view may have a different way to translate an operation in that view to its corresponding database operations. As a result, an operation that is made in one view and then updated in another view will require multiple rounds of translations, thereby increasing the overall complexity and overhead in code development. In addition, using the database as the single source of truth is inefficient because the views are limited to interacting with the database in terms of database structures, including records, fields, and the like. In addition, re-fetching all the information from the database by each view after each operation is slow and inefficient because each view needs to wait for a round trip time for the request to be sent to the database and then the response from the database to be received by the view.
In the present application, improved techniques for a workflow management and automation tool are disclosed. An indication of a user interaction with a user interface element of a user interface used to build a computer process flow is received. A data change action associated with the user interaction is determined. The data change action is validated. Based on the data change action, a computer process flow state associated with the computer process flow is updated to reflect the data change action. In response to the computer process flow state being updated to reflect the data change action, one or more behaviors based on the data change action are triggered.
In the present application, a process automation designer (PAD) that gives the process authors a simple, interactive way to design digitized and automated processes is disclosed. The workflow management and automation tool may provide a number of different UIs/views, including a board view and a diagram view. For example, a visual task board or Kanban board view provides a visual representation of work items, organized into columns that represent different stages of the workflow. The board may be divided into swimlanes, which may represent different teams, projects, or work types. A diagram view or a process diagram provides a visual representation of the flow and dependencies within a process or system. The views may take a workflow process and break it into multiple stages or lanes. A lane is a channel in which activities are grouped. A lane represents one stage in a business process. A lane may be used to sequence process activities. A lane may include many sequenced activities that are grouped in a logical way. Typically, a lane is displayed on a board vertically, whereas a swimlane is displayed on a board horizontally. Each stage includes one or more activities, or steps, for an agent to complete. The terms “activities,” “steps,” and “tasks” are herein used interchangeably. Stages can also include automated activities, such as sending an email to a customer when a stage or activity is complete.
The process automation designer (PAD) includes a data manager that provides consistent ways for handling data flows through the workflow management and automation tool, updating the UIs, and storing persistent data to the database by creating a framework with lifecycle hooks. In the framework, components have lifecycles, representing different stages from creation to destruction. Lifecycle hooks provide specific points in the execution flow of a program or application where custom code may be executed. Developers may leverage the lifecycle hooks to perform actions at specific moments during a lifecycle. The framework provides a consistent client side experience in PAD and maintains a centralized computer process flow state/source of truth.
The data manager enables a clearer separation between data and UIs, which enables the building of a single PAD architecture with two distinct UIs (board and diagram views) on top of the same data and the merging of the board (kanban) UI and the diagram UI into one consistent experience. To ensure a consistent behavior whenever a change happens in PAD, any client side data change goes through a defined client side data flow. The central computer process flow state acts as the source of truth of the process on the client. Any views or components may update the source of truth via a defined operation interface provided by the client data manager. Any views or components may listen to and react to changes to the central client data state via a defined interface at the client data manager. This ensures that the client has a centralized consistent client data flow and clear owner of the computer process flow state, and the components or views may react after the changes have been made to the computer process flow state, for example, by updating the view, persisting to the server, or handling errors consistently, with clear separation of concerns.
The behavior handlers may include a database persist behavior handler 109, a diagram view behavior handler 110, a board view behavior handler 111, and an undo-redo behavior handler 112. Database persist behavior handler 109 handles the persisting of any state changes that need to be saved to the server. Diagram view behavior handler 110 performs incremental updates to the diagram view for any state changes that may be applied to the diagram view, e.g., adding or updating an activity or a lane of the process. Board view behavior handler 111 updates the board view for any state changes that may be applied to the board view, e.g., adding or updating an activity or a lane of the process. Undo-redo behavior handler 112 tracks the changes/actions on the computer process flow state for undo/redo.
Data flow 100 of the process automation designer is used for the initial loading or the loading of a new process (i.e., switching to a new process). In some embodiments, switching to a new process includes removing all the activities and lanes from the previous process in the computer process flow state. In some embodiments, the initial loading of a process includes setting a special persistData=False flag to ensure that the data is not persisted again to the server.
The improved framework and techniques have many benefits. The framework clearly separates and defines ownerships within the framework. Unlike other traditional techniques, the UIs do not need to calculate the business logic. The framework also enables parallel processing, e.g., updating the UIs immediately and persisting the data to the server in parallel in the background, leading to a much better user experience. It also easily enables features such as undo/redo to hook into the data flow to enable new features almost automatically.
The framework provides a consistent experience when a user creates and edits processes in PAD. The data manager provides a consistent way to handle how the user changes flow through the system and how the user changes are updated. It enables instant UI changes across any views (board and diagram views). It enables automatic persistence on the server in the background. It enables real time validation. It enables automatic undo/redo support for any changes. In addition, it enables consistent UI updates across different views (board vs diagram) on the same data. Ater each operation, synchronization of the operation is done in memory. There is no need for each view to refetch all the information from the database, thereby eliminating the need for each view to wait for a round trip time for the request to be sent to the database and then the response from the database to be received by the view.
At step 202, an indication of a user interaction with a user interface element of a user interface used to build a computer process flow is received. At step 204, a data change action associated with the user interaction is identified.
As illustrated, user interaction layer 300 includes a plurality of modules for handling different types of user interactions, including a process data behavior module 304, an activity behavior module 306, a lane behavior module 308, a swimlane behavior module 310, and an undo-redo behavior module 312. However, user interaction layer 300 is not limited to the modules as shown, and additional modules may be added to user interaction layer 300 for other types of user interactions with other user interface elements of other user interfaces.
In one example, a user 302 may update an activity in a process. The update may include adding, moving, or removing the activity from one of the UIs. An indication of the user interaction (i.e., adding, moving, or removing) with a user interface element (i.e., an activity) of a user interface (e.g., a board view, a diagram view, or a side panel) is received. For example, if user 302 updates the activity via the board view or the diagram view, activity behavior module 306 receives the indication of the user interaction and determines the data change action associated with the user interaction, which is sent to an output 322 of user interaction layer 300. If user 302 updates the activity via a side panel view, an indication of the user interaction is sent to a configData behavior module 305 and then sent to activity behavior module 306, and the data change action/updated data associated with the user interaction is determined, which is sent to output 322 of user interaction layer 300.
In another example, an initialization is received from user 302 via a user interface element of one of the user interfaces. The indication of the user interaction is received by process data behavior module 304 and the data change action/updated data associated with the user interaction is determined, which is sent to output 322 of user interaction layer 300.
In another example, user 302 may configure a lane. The configuration may include adding, removing, or updating the lane from one of the UIs. An indication of the user interaction (i.e., adding, removing, or updating) with a user interface element (i.e., the lane) of a user interface (e.g., a board view or a diagram view) is received. For example, if user 302 configures the lane via the board view or the diagram view, then lane behavior module 308 receives the indication of the user interaction and determines the data change action/updated data associated with the user interaction, which is sent to output 322 of user interaction layer 300.
In yet another example, user 302 may configure a swimlane. The configuration may include adding, removing, or updating the swimlane from one of the UIs. An indication of the user interaction (i.e., adding, removing, or updating) with a user interface element (i.e., the swimlane) of a user interface (e.g., a board view or a diagram view) is received. For example, if user 302 configures the swimlane via the board view or the diagram view, then swimlane behavior module 310 receives the indication of the user interaction and determines the data change action/updated data associated with the user interaction, which is sent to output 322 of user interaction layer 300.
In yet another example, user 302 may undo or redo a previous user interaction with a user interface element of one of the user interfaces. For example, one or more of the UIs may include “undo” or “redo” buttons as user interface elements. If user 302 clicks the undo button via the board view or the diagram view, then undo-redo behavior module 312 receives the indication, and if (Undo Len>0) at 314, then module 318 performs a plurality of steps and determines the data change action, which is sent to output 322 of user interaction layer 300. If user 302 clicks the redo button via the board view or the diagram view, then undo-redo behavior module 312 receives the indication, and if (Redo Len>0) at 316, then module 320 performs a plurality of steps and determines the data change action/updated data, which is sent to output 322 of user interaction layer 300.
Referring back to process 200 in
At validation layer 400, the data change actions/updated data received from output 322 of user interaction layer 300 are validated by a validation behavior module 402 by running a set of validators. A validator may determine whether the data change action should be blocked. At 404, if the data change action should be blocked, then a blocking modal is shown at 406. If the data change action should not be blocked, then a notification may be provided and the data change actions are allowed to pass through as an output at 408.
Referring back to process 200 in
At step 210, in response to the computer process flow state being updated to reflect the data change action, one or more behaviors based on the data change action are triggered.
At computer process flow state changes handling layer 500, different behavior handlers may listen to the notifications of any applicable changes that are allowed by validation layer 400 to pass through as output at 408. In response to a computer process flow state that has been updated, the different behavior handlers may react to any applicable changes. For example, the UIs may be updated to reflect those changes. The behavior handlers may include database persist behavior handler 109, diagram view behavior handler 110, board view behavior handler 111, and undo-redo behavior handler 112.
Database persist behavior handler 109 handles the persisting of any state changes that need to be saved to the server. At step 510, it is determined whether the state change should be persisted to the database. If yes, then requests to the server are sent at step 520. For example, requests to a GraphQL server may be sent. GraphQL is a query language and runtime for application programming interfaces (APIs). At step 530, it is determined whether the request is successful. If the request fails, then a reload is performed at step 538. If the request is successful, then, at step 532, it is determined whether the database server has initiated any data change actions. If there are data changes initiated by the database server, then the computer process flow state is updated at step 534, and then process 500 proceeds back to 322 and step 402 of
Diagram view behavior handler 110 performs incremental updates to the diagram view for any state changes that may be applied to the diagram view, e.g., adding or updating an activity or a lane of the process. In particular, at step 512, it is determined whether the diagram view should be updated based on the state changes. If yes, then incremental updates are constructed and sent to the diagram builder at step 522.
Board view behavior handler 111 updates the board view for any state changes that may be applied to the board view, e.g., adding or updating an activity or a lane of the process. In particular, at step 514, it is determined whether the board view should be updated based on the state changes. If yes, then the data for the board view is constructed at step 524.
Undo-redo behavior handler 112 tracks the changes/actions on the computer process flow state for undo/redo. In particular, at step 516, it is determined whether it is an initial load. If yes, then the undo-redo stack is reset at step 518. If not, then it is determined whether the data is persisted data at step 526. If yes, then the changes/actions are stored on the undo-redo stack at step 528.
With reference to
In some embodiments, validation errors and warnings may be managed consistently and exposed to the users in various features:
However, validation layer 400 is not limited to the above exemplary features only. The validation techniques allow for easy extensions to account for a wide variety of use cases. The above feature set may be built into the no-code workflow builder and does not require any configurations.
Validation layer 400 includes a set of validators. The set of checks that are run by the client-side validators may include:
Validation layer 600 includes a validation behavior module 602. A data structure “create ValidateProcessData” may be used to accept an array of validators as well as a list of post-processors. In some embodiments, each validator may be stored in its respective validator utility (util) file in a validator-utils directory, and each post-processor may be stored in its respective post-processor util file in the same directory. The validators and post-processors may be provided in an index.js file.
The client-side may be implemented as a set of separate utils that can be run in sequence to dynamically build a set of errors. These utils may include a factory function or multiple functions composed together that are provided to the validation behavior 602. They accept and return a common format. They may identify what things are relevant to them, add new errors, and remove their own errors for things that have been resolved. This allows for an easy extension and optimization. The list of validators composed and provided to the validation behavior module 602 can be found in a behaviors/validation/index.js file with each validator's respective utils nested under the validator-utils directory.
Validation layer 600 includes a PROCESS_DATA_UPDATED module 604. When a set of updates is made in the diagram, board, or side panel, the requested updates are passed to the validation layer via a structure PAD_UPDATE PROCESS_DATA. Each validator is run in sequence, passing the results of the previous execution into the next. The latest errors and the actions that need to be performed are collected.
Validation layer 600 includes a post-processors module 606. The post-processors are executed. Post-processors examine the error results and the actions that need to be performed that have been collected during the current iteration of the validation and determine if some other action needs to be taken before allowing the update to be passed along to be stored in computer process flow state and to trigger other behaviors to react to the update. Post-processors determine if the current validation cycle needs to stop executing. Post-processors determine if a separate action needs to be dispatched, such as presenting a modal for confirmation, before continuing. Post-processors determine if the current errors and payload need to be staged for later use.
Validation layer 600 includes a PROCESS_DATA_VALIDATED module 608. Once the validators and post-processors have been run, PAD_PROCESS_DATA_VALIDATED is called and the latest validation error objects are saved.
PAD_PROCESS_DATA_VALIDATED is received by the process-state behavior module in computer process flow state layer 106 (see
At step 701, the output of validation behavior module 602 is received. At step 702, when a set of updates is made in the diagram, board, or side panel, the requested updates are passed to the validation layer via a structure PAD_UPDATE PROCESS DATA. Each validator is executed in sequence. At step 708, the errors for each set of incremental updates are aggregated.
Referring back to
The post-processors may handle the following:
At step 704, PAD_VALIDATED_PAYLOAD is accepted. At step 710, the staged payload and errors are fetched. At step 706, PAD_VALIDATED_PAYLOAD is rejected. At step 712, the staged payload and errors are cleared.
For example, if the post-processors come across an action for requiring confirmation, they may dispatch a modal (step 720) to inform the user that they may be breaking some references (thus causing errors) if they proceed with the action and ask the user if the user wants to continue. If the user rejects the change, then the staged data is cleared and the update is not persisted at step 712. If the user accepts the change, then the update is allowed to pass through and the staged data is fetched and passed along at step 710. There is no need to re-run the validators again since they have already been run and the data has been saved for easy fetching.
Validation errors of a process may be shown in different views.
The process data is maintained by the data manager. When a change on an item is requested in the designer, a set of incremental updates is constructed to insert, update, or remove data. In some embodiments, as an optimization of the client-side logic, the set of incremental changes may be parsed and acted upon by the validator associated with those changes, thereby eliminating the need to check the fields for every stage and every activity in a process every time a change is made in the designer. In other words, a portion of the computer process flow that is affected by the data change action is determined and validation is only performed on that portion of the computer process.
For example, if a user fails to specify the start rule of a single activity, only the one activity needs to be checked and have an error saved for a missing start rule. If there are 10 lanes, each with 10 activities, and a user tries to drag an edge between 2 activities in one of the lanes, then only the activities in that lane need to be checked to ensure a loop is not created or if a redundant edge is created. There is no need to check every activity in every lane because they are not affected. Changing the value of a mandatory field does not affect start rules, and therefore loop/redundant edge detection and reference validation may be skipped. Since an incremental change is limited to a subset of the whole process (e.g., just a single item) and the things that the validators care about do not always overlap, parsing the incremental update allows for a more granular look at the changes being made and more control in running only checks that are necessary.
Although the foregoing embodiments have been described in some detail for purposes of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways of implementing the invention. The disclosed embodiments are illustrative and not restrictive.
