Instantiating a filter for the process graph of an RPA workflow

Abstract

A system and method are provided for instantiating a filter for a process graph. A process graph of a workflow is received. Context data associated with the process graph is stored. A filter is instantiated to filter the process graph based on the stored context data. The filtered process graph is output.

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims priority to U.S. Utility Application No. 17 / 031,138, filed September 24, 2020, the disclosure of which is incorporated by reference in its entirety herein.

[0002] The present invention relates generally to process mining for robotic process automation (RPA), and more particularly to instantiating filters for process graphs of RPA workflows for RPA process mining. [Background technology]

[0003] Robotic Process Automation (RPA) is a form of process automation that uses software robots to automate workflows. RPA may be implemented to automate repetitive and / or labor-intensive tasks to reduce costs and increase efficiency. In RPA process mining, execution of RPA workflows by RPA robots is analyzed to identify trends, patterns, and other analytical measures to improve efficiency and gain a better understanding of the RPA workflows. Such RPA workflow executions are typically represented as process graphs. Various filters may be applied to such process graphs to analyze the RPA workflow executions.

[0004] Sometimes, multiple filters may be applied to a process graph to analyze the process graph. In one scenario, a first filter is initially applied to the process graph. A second filter is then applied to the filtered process graph, which was previously filtered according to the first filter. This results in the second filter being defined to filter the process graph based on the results of filtering by the first filter. However, if the first filter is then modified or otherwise removed, the filtering provided by the second filter may differ from that originally intended. Conventional approaches do not address this problem. Summary of the Invention

[0005] According to one or more embodiments, a system and method are provided for instantiating a filter for a process graph. A process graph of a workflow is received. Context data associated with the process graph is stored. A filter is instantiated to filter the process graph based on the stored context data. The filtered process graph is output.

[0006] In one embodiment, the context data includes the state of the application prior to instantiation of the filter. In another embodiment, the context data includes a copy of the process graph in a state prior to instantiation of the filter. In another embodiment, the context data includes a transcript of the process graph at a time prior to instantiation of the filter.

[0007] In one embodiment, the process graph has been previously filtered by a previous filter, and the instantiated filter is defined based on the previously filtered process graph.

[0008] A previous filter modification may be received to modify a previously filtered process graph. The process graph may be filtered at a time after receiving the previous filter modification based on stored context data associated with the process graph at a time immediately prior to instantiation.

[0009] In one or more embodiments, the filter includes a loop depth filter or an activity filter. In one embodiment, the workflow is a robotic process automation (RPA) workflow.

[0010] These and other advantages of the present invention will become apparent to those skilled in the art upon review of the following detailed description and accompanying drawings. [Brief description of the drawings]

[0011] [Figure 1] FIG. 1 is an architectural diagram illustrating a robotic process automation (RPA) system, according to one embodiment of the present invention.

[0012] [Diagram 2] FIG. 1 is an architectural diagram illustrating an example of a deployed RPA system, according to an embodiment of the present invention.

[0013] [Diagram 3] FIG. 1 is an architectural diagram illustrating a simplified example deployment of an RPA system according to an embodiment of the present invention.

[0014] [Figure 4] FIG. 1 illustrates an exemplary workflow.

[0015] [Diagram 5] FIG. 2 illustrates a method for instantiating a filter to filter a process graph according to one embodiment of the present invention.

[0016] [Figure 6] FIG. 5 illustrates an exemplary process graph associated with the workflow illustrated in FIG. 4 that may be analyzed in accordance with one embodiment of the present invention.

[0017] [Figure 7] FIG. 2 illustrates an exemplary filtered process graph filtered according to a loop depth filter in accordance with one embodiment of the present invention.

[0018] [Figure 8] FIG. 4 illustrates an exemplary filtered process graph filtered according to an activity filter in accordance with one embodiment of the present invention.

[0019] [Figure 9] 1 is a block diagram of a computing system according to one embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0020] Robotic Process Automation (RPA) is used to automate workflows and processes. FIG. 1 is an architecture diagram of an RPA system 100, according to one or more embodiments. As shown in FIG. 1, the RPA system 100 includes a designer 102 that enables a developer to design an automation process. More specifically, the designer 102 facilitates the development and deployment of RPA processes and robots to perform activities within the process. The designer 102 can provide solutions for application integration, as well as automation of business processes for third-party applications, management information technology (IT) tasks, and contact center operations. One commercial example of an embodiment of the designer 102 is UiPath Studio®.

[0021] When designing automation of a rule-based process, the developer controls the execution order and relationships between a custom set of steps developed within the process, defined herein as "activities." Each activity may include an action such as clicking a button, reading a file, writing to a log panel, etc. In some embodiments, processes may be nested or embedded.

[0022] Some types of processes may include, but are not limited to, sequences, flowcharts, finite state machines (FSMs), and / or global exception handlers. Sequences may be particularly suitable for linear processes, allowing flow from one activity to another without cluttering the process. Flowcharts may be particularly suitable for more complex business logic, allowing the integration of decisions and the connection of activities in more diverse ways through multiple branching logic operators. FSMs may be particularly suitable for large workflows. FSMs may use a finite number of states during their execution that are triggered by conditions (i.e., transitions) or activities. Global exception handlers may be particularly suitable for determining the behavior of a workflow when an execution error is encountered and for debugging the process.

[0023] Once a process is developed in the designer 102, the execution of the business process is orchestrated by the conductor 104, which orchestrates one or more robots 106 that execute the process developed in the designer 102. One commercial example of an embodiment of the conductor 104 is UiPath Orchestrator®. The conductor 220 facilitates the creation, monitoring, and management of the deployment of resources in the RPA environment. In one example, the conductor 104 is a web application. The conductor 104 can also serve as an integration point with third-party solutions and applications.

[0024] The conductor 104 can manage a fleet of RPA robots 106 by connecting and running the robots 106 from a centralized point. The conductor 104 can have various capabilities including, but not limited to, provisioning, deployment, configuration, queuing, monitoring, logging, and / or providing interconnectivity. Provisioning may include creating and maintaining connections between the robots 106 and the conductor 104 (e.g., web applications). Deployment may include ensuring correct delivery of package versions to the robots 106 assigned for execution. Configuration may include maintaining and delivering robot environment and process configurations. Queuing may include providing management of queues and queue items. Monitoring may include tracking robot identification data and maintaining user permissions. Logging may include storing and indexing logs in a database (e.g., an SQL database) and / or another storage mechanism (e.g., ElasticSearch®, which provides the ability to store and quickly query large data sets). The conductor 104 can provide interconnectivity by acting as a centralized point of communication for third-party solutions and / or applications.

[0025] The robot 106 is an execution agent that executes the processes built in the designer 102. One commercial example of some embodiments of the robot 106 is UiPath Robots®. Types of robots 106 may include, but are not limited to, attended robots 108 and unattended robots 110. Attended robots 108 are triggered by a user or user events and operate in collaboration with a human user on the same computing system. Attended robots 108 can help a human user accomplish various tasks and may be triggered directly by a human user and / or user events. For attended robots, the conductor 104 may provide a centralized process deployment and logging medium. In certain embodiments, attended robots 108 can only be launched from a "robot tray" or a command prompt within a web application. Unattended robots 110 operate in an unattended mode within a virtual environment and can be used to automate many processes, such as high-volume back-end processes. The unattended robot 110 can be responsible for providing remote execution, monitoring, scheduling, and work queue support. Both attended and unattended robots can automate a variety of systems and applications, including, but not limited to, mainframes, web applications, VMs, enterprise applications (e.g., enterprise applications produced by SAP®, SalesForce®, Oracle®, etc.), and computing system applications (e.g., desktop and laptop applications, mobile device applications, wearable computer applications, etc.).

[0026] In some embodiments, a robot 106 installs the Microsoft Windows Service Control Manager (SCM) management service by default. As a result, such a robot 106 can open an interactive Windows session under the local system account and have Windows service rights. In some embodiments, a robot 106 can be installed in user mode with the same rights as the user under which a given robot 106 is installed.

[0027] The robot 106 in some embodiments is divided into several components, each dedicated to a specific task. The robot components in some embodiments include, but are not limited to, an SCM managed robot service, a user mode robot service, an executor, an agent, and a command line. The SCM managed robot service manages and monitors the Windows session and acts as a proxy between the conductor 104 and the execution host (i.e., the computing system on which the robot 106 executes). These services are trusted with the robot 106's credentials and manage the credentials. The console application is launched by the SCM under the local system. The user mode robot service in some embodiments manages and monitors the Windows session and acts as a proxy between the conductor 104 and the execution host. The user mode robot service can be trusted with the robot 106's credentials and manage the credentials. If the SCM managed robot service is not installed, the Windows application may be launched automatically. The executors can execute a given job under the Windows session (e.g., they can execute workflows) and can be aware of per-monitor dots per inch (DPI) settings. An agent may be a Windows Presentation Foundation (WPF) application that displays available jobs in a system tray window. An agent may be a client of a service. An agent can request to start or stop jobs and change settings. A command line is a client of a service, a console application that can request to start jobs and wait for their output. Splitting up robot components can help developers, support users, and allow a computing system to more easily execute, identify, and track what each robot component is doing.Special behaviors may be configured per robot component, such as, for example, setting different firewall rules for executors and services. As a further example, executors may be aware of per-monitor DPI settings in some embodiments, such that workflows may be executed at any DPI regardless of the configuration of the computing system on which they were created.

[0028] Figure 2 illustrates an RPA system 200 according to one or more embodiments. The RPA system 200 may be or may be a part of the RPA system 100 of Figure 1. It should be noted that the "client side," "server side," or both may include any desired number of computing systems without departing from the scope of the present invention.

[0029] As shown on the client side in this embodiment, the computing system 202 includes one or more executors 204, agents 206, and designers 208. In other embodiments, the designers 208 may not be running on the same computing system 202. The executors 204 (which may be robotic components as described above) execute processes, and in some embodiments, multiple business processes may be running simultaneously. In this example, the agent 206 (e.g., a Windows service) is the single point of contact for managing the executors 204.

[0030] In some embodiments, a robot represents an association between a machine name and a user name. A robot can manage multiple executors simultaneously. On a computing system that supports multiple interactive sessions running simultaneously (e.g., Windows Server 2012), multiple robots may be running simultaneously (e.g., in a high density (HD) environment) in separate Windows sessions, each using a unique user name.

[0031] The agent 206 is also responsible for transmitting the status of the robot (e.g., periodically sending "heartbeat" messages to indicate that the robot is still functioning) and for downloading the required versions of packages to be executed. Communication between the agent 206 and the conductor 212 is, in some embodiments, initiated by the agent 206. In an example notification scenario, the agent 206 may open a WebSocket channel that is later used by the conductor 212 to send commands (e.g., start, stop, etc.) to the robot.

[0032] As shown on the server side in this embodiment, the presentation layer includes a web application 214, an Open Data Protocol (OData) Representational State Transfer (REST) ​​Application Programming Interface (API) endpoints 216, and a notification monitoring API 218. The server-side service layer includes an API implementation / business logic 220. The server-side persistence layer includes a database server 222 and an indexer server 224. The conductor 212 includes a web application 214, an OData REST API endpoint 216, a notification monitoring API 218, and an API implementation / business logic 220.

[0033] In various embodiments, most actions performed by a user in the conductor 212 interface (e.g., via browser 210) are performed by calling various APIs. Such actions may include, but are not limited to, starting a job on a robot, adding / removing data in a queue, scheduling a job to run unattended, etc. Web application 214 is the visual layer of the server platform. In this embodiment, web application 214 uses Hypertext Markup Language (HTML) and JavaScript (JS). However, any desired markup language, scripting language, or any other format may be used without departing from the scope of the invention. A user interacts with web pages from web application 214, in this embodiment, via browser 210, to perform various actions and control conductor 212. For example, a user can create robot groups, assign packages to robots, analyze logs per robot and / or per process, start and stop robots, etc.

[0034] In addition to the web application 214, the conductor 212 also includes a services layer that exposes an OData REST API endpoint 216 (or other endpoints may be implemented without departing from the scope of the invention). The REST API is consumed by both the web application 214 and the agent 206, which in this exemplary configuration is the supervisor of one or more robots on the client computer.

[0035] The REST API in this embodiment covers the functionality of configuration, logging, monitoring, and queuing. The configuration REST endpoint may be used in some embodiments to define and configure application users, permissions, robots, assets, releases, and environments. The logging REST endpoint may be useful for logging different information, such as errors, explicit messages sent by the robot, and other environment specific information. The deployment REST endpoint may be used by the robot to query the package version that should be executed when the start job command is used in the conductor 212. The queuing REST endpoint may be involved in managing queues and queue items, such as adding data to the queue, getting transactions from the queue, setting the state of transactions, etc. The monitoring REST endpoint monitors the web application 214 and the agent 206. The notification monitoring API 218 may be a REST endpoint used to register the agent 206, deliver configuration settings to the agent 206, and send / receive notifications from the server and the agent 206. The notification monitoring API 218 may also use WebSocket communication in some embodiments.

[0036] The server-side persistence layer includes a pair of servers in this exemplary embodiment: a database server 222 (e.g., a SQL server) and an indexer server 224. The database server 222 in this embodiment stores configurations for robots, robot groups, associated processes, users, roles, schedules, etc. This information is managed, in some embodiments, via a web application 214. The database server 222 can also manage queues and queue items. In some embodiments, the database server 222 can store messages logged by the robots (in addition to or instead of the indexer server 224). The indexer server 224 is optional in some embodiments and stores and indexes information logged by the robots. In certain embodiments, the indexer server 224 may be disabled via a configuration setting. In some embodiments, the indexer server 224 uses ElasticSearch®, an open source project full-text search engine. Messages logged by the robot (e.g., using activities such as logging a message or writing a line) may be sent via a logging REST endpoint to the indexer server 224, where they are indexed for future use.

[0037] FIG. 3 is an architecture diagram illustrating a simplified example deployment of an RPA system 300, according to one or more embodiments. In some embodiments, the RPA system 300 may be or include the RPA systems 100 and / or 200 of FIGS. 1 and 2, respectively. The RPA system 300 includes multiple client computing systems 302 that execute robots. The computing systems 302 may communicate with a conductor computing system 304 via web applications executed thereon. The conductor computing system 304 in turn communicates with a database server 306 and an optional indexer server 308. With respect to FIGS. 2 and 3, it should be noted that although web applications are used in these embodiments, any suitable client / server software may be used without departing from the scope of the present invention. For example, the conductor may execute a server-side application that communicates with a non-web-based client software application on the client computing system.

[0038] 4 illustrates an example workflow 400. Workflow 400 may be an RPA workflow that is automatically executed by one or more RPA robots. The RPA robots may be implemented by RPA system 100 of FIG. 1, RPA system 200 of FIG. 2, and / or RPA system 300 of FIG. 3. It should be appreciated that workflow 400 may be any suitable process that can be modeled as a workflow and is not limited to an RPA workflow.

[0039] The workflow 400 includes multiple activities 402-430 for automatically processing and paying invoices. As shown in Figure 4, the workflow 400 is modeled as a directed graph where each activity 402-430 is represented as a node and each transition between the activities 402-430 is represented as an edge linking the nodes. The transitions between the activities 402-430 represent the execution of the workflow 400 from a source activity to a destination activity. The workflow 400 is executed through various paths between a start 402 and an end 414.

[0040] In process mining, the execution of the workflow 400 may be analyzed to identify trends, patterns, and other analytical measures to improve efficiency and gain a better understanding of the workflow 400. The execution of the workflow 400 may be represented as a process graph. Various filters may be applied to the process graph to allow a user to analyze the execution of the workflow 400. According to the embodiments described herein, contextual data associated with the process graph of the workflow 400 is stored, and a filter is instantiated to filter the process graph based on the stored contextual data. Advantageously, the contextual data associated with the process graph is not lost even if the process graph is subsequently changed, for example, due to modification or removal of a previous filter previously applied to the process graph.

[0041] 5 illustrates a method 500 for instantiating a filter to filter a process graph according to one or more embodiments. Method 500 may be performed by one or more suitable computing devices, such as, for example, computer 900 of FIG.

[0042] In step 502, a process graph of a workflow is received. A process graph is a graph that represents one or more instances of execution of a workflow. In one example, the workflow is workflow 400 of FIG. 4. In one embodiment, the workflow is an RPA workflow that is automatically executed by one or more RPA robots. However, it should be understood that the workflow may be any suitable workflow and is not limited to an RPA workflow. The process graph may be received by loading a previously stored process graph from a storage or memory of the computer system (e.g., memory 906 of FIG. 9) or by receiving a process graph transmitted from a remote computer system.

[0043] The process graph may be in any suitable form. For example, the process graph may be modeled based on BPMN (Business Process Model and Notation), a Petri net, a process tree, or any other suitable notation or format. Figure 6 illustrates an exemplary process graph 600 of the workflow 400 of Figure 4 according to one or more embodiments. The process graph 600 represents multiple instances of execution of the workflow 400. Each instance of execution of the workflow 400 may be associated with a particular case and identified by a case identifier.

[0044] The process graph may be generated based on execution data associated with the workflow. In one embodiment, the execution data associated with the workflow includes an event log of the execution of the workflow. An event log is a log that records events of the execution of the workflow. Each event in the event log defines the execution of a particular activity having a particular timestamp and a particular instance identifier. It should be understood that the execution data may include any data that represents the execution of the workflow and is not limited to an event log.

[0045] In step 504, context data associated with the process graph is stored. The context data may include any data associated with the current state of the process graph (i.e., the state of the process graph before and immediately before instantiating a filter to filter the process graph in step 506). The context data is stored in a memory or storage, such as, for example, memory 906 of FIG.

[0046] In one embodiment, in the replication on demand approach, the context data associated with the process graph includes the current state of, or data about, a set of one or more process dashboard applications (i.e., the state before and immediately prior to instantiating the filters to filter the process graph in step 506). The process dashboard applications are applications for process analysis of workflows. In this embodiment, the current state of the process dashboard applications is replicated to instantiate the filters in the current state, but the replicated current state can be modified for subsequent user interactions. In general, the current state is determined by the combined state of all filters and input data.

[0047] In one embodiment, in a process duplication approach, the context data associated with the process graph includes a duplicate or restoration of the process graph in its current state (i.e., the state before and immediately prior to instantiating a filter to filter the process graph in step 506). The process graphs may be displayed separately such that a user can instantiate, remove, or modify filters on a process graph depicted on one display without affecting other process graphs depicted on other displays.

[0048] In one embodiment, in a re-filtering approach that uses a cache layer, the context associated with the instantiation of the filter includes the current execution record of the process graph (i.e., the execution record of the process graph before and immediately before instantiating the filter to filter the process graph in step 506). The execution record is stored in a cache layer, allowing it to be quickly retrieved without subsequent recomputation in order to filter the process graph based on the execution record.

[0049] In step 506, a filter is instantiated to filter the process graph based on the stored context data. Instantiating a filter refers to creating a filter by defining parameters for how the process graph is filtered and applying the created filter to filter the process graph. The instantiated filter filters the process graph based on the stored context data by retrieving the stored context data from a storage or memory (e.g., memory 906 of FIG. 9 ) and applying the instantiated filter to the retrieved context data. The filter may be instantiated in response to a user input. The filter may be any filter suitable for filtering a process graph. Exemplary filters include a loop depth filter and an activity filter.

[0050] The loop depth of an activity refers to the number of times that the activity loops or repeats itself in a process graph. For example, in the process graph 600 of Figure 6, the loop behavior 604 is represented as an edge that loops back to the node 602 associated with the activity "Retrieve Invoice Confirmation," representing repeating the activity 274 times. The loop depth filter filters nodes in a process graph to identify those that do not meet a user-defined loop depth threshold.

[0051] FIG. 7 illustrates an example filtered process graph 700 filtered according to a loop depth filter, according to one or more embodiments. The filtered process graph 700 illustrated in FIG. 7 is the process graph 600 of FIG. 6 filtered with a loop depth filter. The loop depth filter is defined to have a loop depth threshold of 2 based on a user selection interface 702. Thus, the process graph 600 of FIG. 6 is filtered to identify cases that do not meet the loop depth threshold (i.e., cases that perform an activity more than once). As illustrated in FIG. 7, the loop depth filter is applied to the process graph 600 to expand node 602 (of FIG. 6) to nodes 704 and 706, where node 704 corresponds to the case associated with an initial instance of execution of the "check invoice final" activity and node 706 corresponds to the case associated with a repeated instance of execution of the "check invoice final" activity (i.e., a case that repeats the "check invoice final" activity more than once).

[0052] The filtered process graph is output at step 508. The filtered process graph may be output, for example, by displaying the filtered process graph on a display device of the computer system (e.g., display 910 of FIG. 9) or by storing the filtered process graph in memory or storage of the computer system (e.g., memory 906 of FIG. 9).

[0053] In one embodiment, the steps of method 500 may be repeated iteratively any number of times to apply any number of filters on the process graph. For example, FIG. 8 illustrates an exemplary filtered process graph 800 that has been filtered according to an activity filter, according to one or more embodiments. The filtered process graph 800 is the process graph 700 of FIG. 7 that has been further filtered with an activity filter. The process graph 700 has previously been filtered with a previous loop depth filter having a loop depth threshold of 2, as described above with respect to FIG. 7. According to method 500, the process graph 700 is received (step 502), context data associated with the process graph 700 is stored (step 504), an activity filter is instantiated (step 506) to filter the process graph based on the stored context data to generate the filtered process graph 800, and the filtered process graph 800 is output. The activity filter is defined based on the previously filtered process graph 700. Specifically, the activity filter is defined to identify all instances that include a node for the activity "Final Invoice Confirmation (2+)".

[0054] In one embodiment, a modification of the previous filter may be received to modify a previously filtered process graph. For example, in the filtered process graph 800, a modification of the previous loop depth filter may be received to remove the loop depth filter or to modify the parameters of the loop depth filter to change the loop depth threshold. Such a modification of the previous loop depth filter would result in a node for the activity "final review of invoice (2+)" no longer being present. However, according to the embodiment described herein, an activity filter defined to identify all instances that include a node for the activity "final review of invoice (2+)" filters the process graph based on stored context data for the time immediately prior to instantiation, thus generating the filtered process graph 800, even if a node for the activity "final review of invoice (2+)" no longer exists due to a modification of the previous loop depth filter.

[0055] FIG. 9 is a block diagram illustrating a computing system 900 configured to perform the methods, workflows, and processes described herein, including the method illustrated in FIG. 5, according to an embodiment of the present invention. In some embodiments, the computing system 900 may be one or more of the computing systems depicted and / or described herein. The computing system 900 includes a bus 902 or other communication mechanism for communicating information and a processor 904 coupled to the bus 902 for processing information. The processor 904 may be any type of general-purpose or special-purpose processor, including a central processing unit (CPU), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a graphics processing unit (GPU), multiple instances thereof, and / or any combination thereof. The processor 904 may also have multiple processing cores, at least some of which may be configured to perform unique functions. In some embodiments, multiple parallel processing may be used.

[0056] The computing system 900 further includes a memory 906 for storing information and instructions to be executed by the processor 904. The memory 906 can be comprised of any combination of random access memory (RAM), read-only memory (ROM), flash memory, cache, static storage devices such as magnetic or optical disks, or any other type of non-transitory computer-readable medium or combination thereof. The non-transitory computer-readable medium may be any available medium that can be accessed by the processor 904 and may include volatile media, non-volatile media, or both. The medium may also be removable, non-removable, or both.

[0057] Additionally, the computing system 900 includes a communications device 908, such as a transceiver, to provide access to a communications network via wireless and / or wired connections in accordance with any currently existing or future implemented communications standards and / or protocols.

[0058] The processor 904 is further coupled via bus 902 to a display 910 suitable for displaying information to a user. The display 910 may also be configured as a touch display and / or any suitable tactile I / O device.

[0059] A keyboard 912 and cursor control devices 914, such as a computer mouse, touchpad, etc., are further coupled to the bus 902 to allow a user to interface with the computing system. However, in certain embodiments, a physical keyboard and mouse may not be present and the user may interact with the device solely through the display 910 and / or touchpad (not shown). Any type and combination of input devices may be used as a matter of design choice. In certain embodiments, there are no physical input devices and / or displays. For example, a user may interact with the computing system 900 remotely through another computing system in communication with it, or the computing system 900 may operate autonomously.

[0060] The memory 906 stores software modules that provide functionality when executed by the processor 904. The modules include an operating system 916 for the computing system 900 and one or more additional functional modules 918 configured to perform all or a portion of the processes described herein or derivations thereof.

[0061] Those skilled in the art will appreciate that the "system" may be embodied as a server, an embedded computing system, a personal computer, a console, a personal digital assistant (PDA), a mobile phone, a tablet computing device, a quantum computing system, or any other suitable computing device or combination of devices without departing from the scope of the present invention. Presenting the functions described above as being performed by the "system" is in no way intended to limit the scope of the present invention, but rather to provide an example of many embodiments of the present invention. Indeed, the methods, systems, and apparatus disclosed herein may be implemented in localized and distributed forms consistent with computing technologies, including cloud computing systems.

[0062] It should be noted that some of the features of the systems described herein have been presented as modules to more fully emphasize their implementation independence. For example, the modules may be implemented as hardware circuits comprising off-the-shelf semiconductors such as custom Very Large Scale Integration (VLSI) circuits or gate arrays, logic chips, transistors, or other discrete components. The modules may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, and the like. The modules may also be implemented at least partially in software for execution by various types of processors. The identified units of executable code may include one or more physical or logical blocks of computer instructions, which may be organized as objects, procedures, or functions, for example. Nevertheless, the executable files of the identified modules may include different instructions stored in different locations that, although not necessarily physically located together, comprise a module when logically coupled together and achieve the stated purpose for the module. Furthermore, the modules may be stored on a computer readable medium, which may be, for example, a hard disk drive, a flash device, a RAM, a tape, and / or any other such non-transitory computer readable medium used to store data without departing from the scope of the present invention. Indeed, a module of executable code may be a single instruction, or many instructions, and may be distributed across several different code segments, among different programs, and even across several memory devices. Similarly, operational data may be identified and illustrated herein in modules, and may be embodied in any suitable form and organized within any suitable type of data structure. Operational data may be collected as a single data set, may be distributed across different locations, including different storage devices, or may exist, at least in part, simply as electronic signals on a system or network.

[0063] The above merely illustrates the principles of the present disclosure. Thus, it will be understood that those skilled in the art can devise various configurations that embody the principles of the present disclosure and fall within the spirit and scope thereof, although not explicitly described or illustrated herein. Furthermore, all examples and conditional language recited herein are merely for educational purposes to help the reader understand the principles of the present disclosure and the concepts contributed by the inventor to promote the present technology, and should not be construed as being limited to such specifically recited examples and conditions. Moreover, all statements herein reciting the principles, aspects, and embodiments of the present disclosure, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Moreover, such equivalents are intended to include both currently known equivalents as well as equivalents developed in the future.

Claims

1. storing context data associated with a state of a process graph representing one or more instances of execution of a workflow, the process graph having been previously filtered by a previous filter; instantiating a filter based on the process graph; receiving a modification of the previous filter to modify the process graph; filtering the process graph at a time subsequent to the receipt of the modification of the previous filter based on the stored context data associated with the process graph at a time immediately prior to instantiation using the instantiated filter; outputting the filtered process graph; 4. A computer-implemented method comprising:

2. The computer-implemented method of claim 1 , wherein the contextual data comprises a state of an application prior to the instantiation of the filter.

3. The computer-implemented method of claim 1 , wherein the context data comprises a copy of the process graph in a state prior to the instantiation of the filter.

4. The computer-implemented method of claim 1 , wherein the context data comprises a run record of the process graph at a time prior to the instantiation of the filter.

5. The computer-implemented method of claim 1 , wherein the workflow is a robotic process automation (RPA) workflow.

6. The computer-implemented method of claim 1 , wherein the filter comprises a loop depth filter.

7. The computer-implemented method of claim 1 , wherein the filter comprises an activity filter.

8. a memory for storing computer instructions; at least one processor configured to execute the computer instructions; 11. An apparatus comprising: storing context data associated with a process graph of a workflow, the context data including a state of the application prior to instantiation of a filter; instantiating the filter to filter the process graph based on the stored context data; outputting the filtered process graph; configured to cause the at least one processor to execute Device.

9. The apparatus of claim 8 , wherein the context data further comprises a copy of the process graph in a state prior to the instantiation of the filter.

10. The apparatus of claim 8 , wherein the context data further comprises a run record of the process graph at a time prior to the instantiation of the filter.

11. The apparatus of claim 8 , wherein the process graph has been previously filtered by a previous filter, and the instantiated filter is defined based on the previously filtered process graph.

12. The operations further include receiving a modification of the previous filter to modify a previously filtered process graph, and instantiating a filter to filter the process graph based on the stored context data, filtering the process graph at a time subsequent to the receipt of the modification of the previous filter based on the stored context data associated with the process graph at a time immediately prior to the instantiation. The apparatus of claim 8 , comprising:

13. A non-transitory computer-readable medium storing computer program instructions, the computer program instructions, when executed by at least one processor, storing context data associated with a process graph of the workflow; instantiating a filter to filter the process graph based on the stored context data, the context data including a copy of the process graph in a state prior to the instantiation of the filter; outputting the filtered process graph; causing the at least one processor to perform operations including: Non-transitory computer-readable medium.

14. The non-transitory computer-readable medium of claim 13 , wherein the contextual data further comprises a state of an application prior to the instantiation of the filter.

15. The non-transitory computer-readable medium of claim 13 , wherein the context data further comprises a run record of the process graph at a time prior to the instantiation of the filter.

16. 14. The non-transitory computer-readable medium of claim 13, wherein the workflow is a robotic process automation (RPA) workflow.

Images