Workflow approval method

Abstract

The invention relates to the technical field of process management, and discloses a workflow approval method, which comprises the following steps of: calling a process definition and a process form corresponding to a target process, performing sequential approval on nodes in the target process based on the process definition, and determining a corresponding target group when executing to a node with an approver rule; based on the flow form data and the flow context information, all members meeting conditions are screened out to form an actual approver set, so that the approver screening process can accurately perceive the real-time state of flow execution and historical flow examples, approval tasks are allocated to the members in the actual approver set, and after the approval task of the current node is completed, the approval task of the current node is allocated to the members in the actual approver set. According to the method, the next transfer node can be determined based on the transfer relationship between the nodes and the process form, so that complex and flexible examination and approval logic is supported, the flexibility of process examination and approval is improved while the examination and approval process is standardized, and the method adapts to the actual scene that the internal organization structure of an enterprise is complex and the business demand is rapidly iterated.

Description

A workflow approval method Technical Field

[0001] This invention relates to the field of process management technology, specifically to a workflow approval method. Background Technology

[0002] As businesses continue to expand and become more complex, and as digital transformation accelerates, traditional process management methods are gradually revealing their limitations. In order to respond more efficiently to rapidly changing market scenarios and business needs, visual process configuration has emerged. Visual process configuration, through a graphical interface and guided operation, enables business personnel without technical backgrounds to participate in the design and optimization of processes. This approach greatly reduces the technical threshold and shortens the cycle from requirement proposal to implementation.

[0003] However, with the increasing complexity of internal organizational structures and the ever-changing nature of business needs, the overly simplistic setup of approval personnel at each node has poor scalability and lacks the ability to perceive dynamic contexts and historical process instances. This makes it difficult to achieve complex and flexible approval logic, such as dynamically determining the approver for the next stage based on the handler or result of the previous stage. Summary of the Invention

[0004] This invention provides a workflow approval method to solve the problem that traditional approval processes cannot cope with the complex and ever-changing business needs.

[0005] In a first aspect, the present invention provides a workflow approval method, the method comprising: responding to receiving a target workflow execution instruction, invoking a workflow definition and workflow form associated with the target workflow, wherein the workflow definition data includes at least multiple nodes, flow relationships between nodes, and approver rules configured for at least one node, the approver rules being associated with at least one predefined group, the group being used to define a set of candidate approvers, and the workflow form data including at least one task approval permission configured for at least one node; performing sequential approval on nodes in the target workflow based on the workflow definition; when execution reaches the current node with an approver rule, determining the corresponding target group according to the approver rule; based on the workflow form data and workflow context information, selecting all members meeting preset conditions from the target group to form an actual approver set, and assigning approval tasks to members in the actual approver set, so that the actual approvers perform task approval based on the corresponding task approval permissions; and determining the next flow node based on the flow relationships between nodes and the workflow form data after the approval task at the current node is completed.

[0006] In one optional implementation, the process form is obtained through the following steps: in response to receiving a form customization instruction, a visual operation interface is provided to the user, the operation interface including a form component library and a form canvas area; the user's selection operation in the form component library and drag operation to the form canvas area are received, and the selected form component is rendered and positioned at the corresponding position in the form canvas area; the user's configuration operation for the current form component is received, the configuration operation including at least setting the configuration data corresponding to the form component; the steps of receiving the user's selection operation in the form component library and drag operation to the form canvas area are repeated until the user's configuration operation for the current form component is received, until the customized process form is generated.

[0007] In one optional implementation, the process form is obtained through the following steps: in response to receiving an external form association instruction, external form data is invoked, and external form attribute information entered by the user for the external form is received through an external form registration interface; the external form data and external form attribute information are merged to obtain an external form, wherein the external form attribute information includes at least a form identifier, and the external form data has been developed by the upstream system; the external form is bound to at least one target process definition, so that when an execution instruction is initiated for the target process, the external form is invoked through an interface based on the form identifier and the target process identifier, serving as the process form corresponding to the target process.

[0008] In one optional implementation, the grouping includes at least a role group, a user group, a business group, and an approval group. The business group is defined by a logical expression, and the approval group is associated with the process initiator and pre-configured as an approver path with an approval order. The step of filtering all members meeting preset conditions from the target group as the actual approver set based on the process form data and process context information includes: when the target group is a role group, filtering members whose jurisdiction matches the region information from the members of the role group based on the region information in the process context information to form the actual approver set; or, when the target group is a role group, filtering members whose jurisdiction matches the region information from the members of the role group to form the actual approver set. When the target group is a user group, all pre-configured members in the user group are determined as the actual approver set. Alternatively, when the target group is a business group, the field values ​​corresponding to the logical expression variables in the process form data are substituted into the logical expression of the business group for calculation to determine the actual approver set. Alternatively, when the target group is an approval group, based on the initiator identity corresponding to the target process, the approval group related to the initiator and its corresponding approver path are matched, all users defined in the approver path are determined as the actual approver set, and the corresponding approval order is recorded so that subsequent actual approvers can approve tasks based on the approval order.

[0009] In an optional implementation, the method further includes: in response to receiving a target process adjustment instruction, obtaining process definition data corresponding to the target process; displaying the logical structure of the process definition through a visual interface, the logical structure including at least multiple nodes and flow relationships between nodes; receiving a user's modification operation on the logical structure; generating modified process definition data according to the modification operation, and binding the modified process definition data to the target process.

[0010] In an optional implementation, before binding the modified process definition data to the target process, the method further includes: pre-storing the modified process definition data when the target process is detected to be in an approval state; and binding the modified process definition data to the target process after the target process is detected to be approved.

[0011] In an optional implementation, before binding the modified process definition data to the target process, the method further includes: inputting preset process execution parameters and process form data into the modified process definition data, performing a simulation to obtain the simulation result; if the simulation result meets the preset process requirements, binding the modified process definition data to the target process; if the simulation result does not meet the preset process requirements, sending a prompt message indicating a process execution error to the user so that the user can adjust the process definition data.

[0012] In one optional implementation, determining the next flow node based on the flow relationship between the nodes and the process form data includes: when the process executes to a conditional branch node, obtaining multiple candidate branches associated with the conditional branch node and their respective configured condition judgment rules; calculating the condition judgment rules of the multiple candidate branches based on the process form data to obtain a calculation result; if the calculation result indicates that only one candidate branch's condition is satisfied, determining the node corresponding to the candidate branch whose condition is satisfied as the next flow node; if the calculation result indicates that at least two candidate branches' conditions are satisfied, determining the node corresponding to the candidate branch with the highest priority as the next flow node according to the preset priority order of each candidate branch; if the calculation result indicates that no candidate branch's condition is satisfied, determining the node corresponding to the preset default branch as the next flow node.

[0013] In an optional implementation, the method further includes: automatically transferring to the next node or assigning the approval task to a preset approver when it is detected that the actual approver set is empty or a member of the actual approver set is a process initiator.

[0014] In an optional implementation, the method further includes: in response to receiving an approval return instruction submitted by the approver of the current node, reverting the approval task to a first approval node for task approval, wherein the first approval node is the approval node specified by the user in the approval return instruction; and after the task approval is completed at the first approval node, transferring the approval task to the current node.

[0015] The present invention has the following technical effects: The workflow approval method provided by the present invention calls the workflow definition and workflow form corresponding to the target workflow, and sequentially approves the nodes in the target workflow based on the workflow definition. When the execution reaches the node with approver rules, the corresponding target group can be determined according to the approver rules. This allows for flexible maintenance of approvers through approval grouping, significantly improving the flexibility of approver configuration. Then, based on workflow form data and workflow context information, all members who meet the preset conditions are selected from the target group to form the actual approver set. This allows the approver selection process to accurately perceive the real-time status of workflow execution and historical workflow examples, making approval decisions more in line with actual business scenarios. Approval tasks are assigned to members in the actual approver set. After the approval task of the current node is completed, the next flow node can be determined based on the flow relationship between nodes and workflow form data until the approval is completed. This supports complex and flexible approval logic, improves the flexibility of workflow approval while standardizing the approval process, and adapts to the actual scenarios of complex internal organizational structures and rapid iteration of business needs within enterprises. Attached Figure Description

[0016] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0017] Figure 1 is a schematic diagram of a first type of workflow approval method according to an embodiment of the present invention; Figure 2 is an example interface diagram of form data read / write permission settings according to an embodiment of the present invention; Figure 3 is a schematic diagram of a second type of workflow approval method according to an embodiment of the present invention; Figure 4 is an example interface diagram of a custom form according to an embodiment of the present invention; Figure 5 is an example interface diagram of an external form according to an embodiment of the present invention; Figure 6 is an example interface diagram of approver flow settings according to an embodiment of the present invention; Figure 7 is an example interface diagram of role group settings according to an embodiment of the present invention; Figure 8 is an example interface diagram of user group settings according to an embodiment of the present invention; Figure 9 is an example interface diagram of business group settings according to an embodiment of the present invention; Figure 10 is an example interface diagram of a business group settings according to an embodiment of the present invention. Figure 11 is an example of an interface for setting up an approval group according to an embodiment of the present invention; Figure 12 is an example of an interface for setting up email sending according to an embodiment of the present invention; Figure 13 is an example of an interface for setting up approval rules according to an embodiment of the present invention; Figure 14 is an example of an interface for setting up approval delegation according to an embodiment of the present invention; Figure 15 is an example of an interface for visualizing the process logic structure according to an embodiment of the present invention; Figure 16 is an example of a process simulation diagram according to an embodiment of the present invention; Figure 17 is a specific example of a workflow approval according to an embodiment of the present invention; Figure 18 is a structural block diagram of a workflow approval system according to an embodiment of the present invention; Figure 19 is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0020] According to an embodiment of the present invention, a workflow approval method embodiment is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0021] This embodiment provides a workflow approval method. Figure 1 is a flowchart of the workflow approval method according to an embodiment of the present invention. As shown in Figure 1, the process includes the following steps: Step S101, in response to receiving a target workflow execution instruction, calling the workflow definition and workflow form associated with the target workflow.

[0022] The process definition data includes at least multiple nodes, the flow relationship between nodes, and approver rules configured for at least one node. The approver rules are associated with at least one predefined group, which is used to define a group of candidate approvers. The process form data includes at least the task approval permissions configured for at least one node.

[0023] This invention allows for pre-setting corresponding process definitions and process form definitions for a target process. The process form includes at least task approval permissions, business form fields, and other business data and permission configurations for at least one node. This clarifies the approval permissions of the node approver and the business data to be processed. The form structure can be generated by manually configuring field information and setting usage permissions through custom menus and drag-and-drop design. The process definition data includes at least multiple nodes (not limited to approval nodes, copy nodes, and processing nodes, etc.), enabling functions beyond just approval and rejection. Nodes can automatically attach and trigger custom actions in different states, improving the automation depth and business fit of the process. The workflow includes the flow relationships and conditions between nodes, and the approver rules configured for at least one node. This supports task approval by approvers from different dimensions, enabling more flexible control of the process. Each approver rule is associated with at least one predefined group, and the group is used to define a set of candidate approval members. For example, if node A is configured with a group named Department A or Department B, then the corresponding candidate approval members are all members of Department A or Department B. Or, if node A is configured with a group named Department Manager, then the corresponding candidate approval members include all members at the level of Department Manager. This is just an example. The workflow definition defines a complete business process by binding workflow form information, configuring workflow conditions and approval nodes.

[0024] In this embodiment of the invention, configuration information related to the process form can be prepared before configuring the process definition. The configuration information may include, but is not limited to, form identifiers (such as form keys) and field information. The form identifier is a unique corresponding value used to associate with the specific process definition. When the target process is executed by calling the Application Programming Interface (API), the corresponding approval process can be initiated and executed by specifying the form identifier. Therefore, when responding to the user's submission of the target process approval instruction, the process definition corresponding to the target process can be called first. Then, based on the form identifier associated with the process definition, the corresponding process form can be called. Finally, the retrieved process definition and process form are associated and integrated to form the complete data set required for the target process approval. The field information is further divided into several applicable categories such as conditions, form permissions, and contacts within the form. Conditions: configured within the node to control the flow of process nodes; Form permissions: configured within the node to control the read and write permissions of the approver on the form data when the flow reaches that node; Contacts within the form: configured within the node to set the approver of that node as a dynamic person within the form.

[0025] Step S102: Based on the process definition, sequentially approve the nodes in the target process.

[0026] Based on the defined process that has been invoked, the approval process can be initiated according to the flow relationship between nodes and the order of approval. The execution of each node can be advanced in sequence. If a node does not require the configuration of approver rules (such as the node where the initiator submits the approval), the node can be completed directly and the process can be automatically advanced to the next node.

[0027] Step S103: When execution reaches the current node with approver rules, determine the corresponding target group according to the approver rules.

[0028] When the current node with approver rules is reached in the embodiment of the present invention, the associated target group, such as Department A, can be matched according to the approver rules set for that node. This is just an example.

[0029] Step S104: Based on the process form data and process context information, select all members who meet the preset conditions from the target group to form the actual approver set, and assign approval tasks to the members in the actual approver set so that the actual approvers can approve tasks based on the corresponding task approval permissions.

[0030] This invention can further filter all members who meet preset conditions from a target group based on process form data and process context information to form an actual approver set. For example, the process form data includes node approval permission requirements, and the process context information includes at least the approver's on-duty status and the applicant's department. Then, members who meet the conditions can be filtered from the target group. For instance, from all members of department A, those on leave can be excluded, and members with business permissions can be extracted to form the actual approver set. Approval tasks can then be assigned to members in the actual approver set, allowing them to perform task approvals based on their corresponding task approval permissions. In this system, task approval permissions can be set for different actual approval members. For example, Department A includes management, frontline employees, and financial specialists. Different levels of personnel have different operation permissions for approval. For instance, frontline employees can view approval tasks but do not have the permission to approve or modify the approval content, while management can not only view approval tasks but also perform operations such as approval / rejection. As shown in Figure 2, read and write permissions for the content in the form can also be set for approvers. Different levels of approvers have different read and write permissions for the content. For instance, frontline employees can only be set to have read permissions, while management can be set to have edit permissions. This is just an example.

[0031] Step S105: After the approval task of the current node is completed, determine the next flow node based on the flow relationship between nodes and the process form data.

[0032] In this embodiment of the invention, after the approval task of the current node is completed, the next flow node to be executed can be determined based on the flow relationship between nodes in the process definition (such as sequential flow, branch flow) and the process form data (such as approval result). For example, if the approval is approved, the flow will proceed to the next node; if the approval is rejected, the flow will proceed to the initiator node, and the approval process of the new node will continue to proceed in sequence until the approval is completed.

[0033] The workflow approval method provided by this invention calls the workflow definition and workflow form corresponding to the target workflow, and sequentially approves the nodes in the target workflow based on the workflow definition. When the execution reaches a node with approver rules, the corresponding target group can be determined according to the approver rules. This allows for flexible maintenance of approvers through approval grouping, significantly improving the flexibility of approver configuration. Then, based on workflow form data and workflow context information, all members who meet preset conditions are selected from the target group to form an actual approver set. This allows the approver selection process to accurately perceive the real-time status of workflow execution and historical workflow examples, making approval decisions more aligned with actual business scenarios. Approval tasks are then assigned to members in the actual approver set. After the approval task at the current node is completed, the next flow node can be determined based on the flow relationship between nodes and workflow form data, until the approval is completed. This supports complex and flexible approval logic, improves the flexibility of workflow approval while standardizing the approval process, and adapts to the actual scenarios of complex internal organizational structures and rapidly iterating business needs within enterprises.

[0034] This embodiment provides a workflow approval method. Figure 3 is a flowchart of the workflow approval method according to an embodiment of the present invention. As shown in Figure 3, the process includes the following steps: Step S301, in response to receiving the target workflow execution instruction, calling the workflow definition and workflow form associated with the target workflow.

[0035] The process definition data includes at least multiple nodes, the flow relationship between nodes, and approver rules configured for at least one node. The approver rules are associated with at least one predefined group, which is used to define a group of candidate approvers. The process form data includes at least the task approval permissions configured for at least one node.

[0036] Specifically, the process form type can be a custom form, and the corresponding process form is obtained through the following steps: In response to receiving a form customization instruction, a visual operation interface is provided to the user, which includes a form component library and a form canvas area; the user's selection operation in the form component library and drag operation in the form canvas area are received, and the selected form component is rendered and positioned in the corresponding position in the form canvas area; the user's configuration operation for the current form component is received, and the configuration operation includes at least setting the configuration data corresponding to the form component; the steps of receiving the user's selection operation in the form component library and drag operation in the form canvas area are repeated until the user's configuration operation for the current form component is received, until the custom process form is generated.

[0037] The process form designed in this embodiment of the invention can be a custom form. When configuring process form information, in response to receiving the user's selected form customization instruction, it indicates that the user has selected a custom form. After selection, a "Design" button will appear in the operation bar of the data. The user can use this button to enter the form design page (visual operation interface) to design the form. The form design page includes a form component library (such as input boxes, radio buttons, etc.) and a form canvas area. The user can select the target component in the form component library by clicking or other operations, triggering the component selection state. The user drags the selected form component to the specified position in the form canvas area, and the drag action is responded to in real time. The component placeholder is previewed in the canvas. When the user releases the drag operation, a visual example of the component is rendered in the canvas according to the coordinates of the drag endpoint, and the basic layout information such as the position and hierarchy of the component is automatically recorded.

[0038] In this embodiment of the invention, after the user selects the target component in the canvas area, they can set the corresponding configuration data for the target component, such as basic attributes, business attributes (the form data corresponding to the component), etc. After completing the configuration, the configuration data can be saved in real time. The above component configuration steps are repeated until the user completes the addition and configuration of all components. After clicking the "Complete" or "Save" buttons, which can be set according to the actual situation, a custom process form can be generated. The example content of the process form can be seen in Figure 4, which is only an example.

[0039] This invention allows for the design of custom forms based on specific needs, making them easy to modify and expand without requiring the entire system to be redeveloped. Simply adjusting the form's structure and logic can meet new requirements, significantly reducing iteration and maintenance costs and improving the flexibility of process configuration.

[0040] In an optional implementation, the process form type can also be an external form, which is obtained through the following steps: in response to receiving an external form association instruction, calling the external form data and receiving the external form attribute information entered by the user through the external form registration interface; merging the external form data and the external form attribute information to obtain the external form, wherein the external form attribute information includes at least a form identifier, and the external form data has been developed by the upstream system; binding the external form to at least one target process definition so that when an execution instruction is issued for the target process, the external form is called through the interface based on the form identifier and the target process identifier, serving as the process form corresponding to the target process.

[0041] The external form designed in this embodiment of the invention does not use the built-in form function. It is developed by the upstream system and the relevant form data is saved. As shown in Figure 5, the form identifier (form key) and related field information (such as form name, type, and other field information, which are not limited) of the external form can be manually entered without designing a form definition. In a specific embodiment, in response to receiving the external form association instruction, the external form registration interface is loaded and displayed. This interface serves as the entry point for the association between the external form and the system process. It can call the external form data developed by the upstream system developers. Users can then manually enter the corresponding attribute information of the external form through the external form registration interface. The attribute information includes at least the form identifier and related field information. After the data is entered, the system can display the external form data. The external form is obtained by integrating the data with the attribute information of the external form. Subsequently, the user can select at least one target process definition and bind the registered external form to the target process definition through the interface. It supports binding one external form to multiple process definitions, or binding one process definition to multiple external forms (adapted to the scenario). Because different flow conditions, node approvers, and read / write permissions of form fields can be configured in the process definition, the relevant form field values ​​must be passed when calling the API interface to execute the process to ensure the correct flow of the process. After the execution command is issued to the target process, the corresponding process form identifier and upstream system interface information can be matched according to the current process identifier, and the external form can be called through the API interface as the process form of the target process for subsequent task approval.

[0042] This invention expands the process carrier to include both custom forms and external forms through an external form registration and binding mechanism, enriching the types and functional coverage of process forms. Furthermore, it enables real-time access to form data via an interface, achieving real-time linkage between external forms and process execution, thereby improving the integrity and continuity of business processes.

[0043] Step S302: Based on the process definition, sequentially approve the nodes in the target process.

[0044] Specifically, the process definition supports various methods such as graphical configuration and JSON data import to define business processes. There are no restrictions on the types of nodes in the process definition, including but not limited to approval nodes, copy nodes, processing nodes, and conditional branches. Approval nodes can perform functions such as approving, canceling, returning, transferring, and adding / removing signatures for tasks. Copy nodes can be set to copy tasks to designated members when the process flows to the current route. Copy settings can be configured within the node, such as copying upon approval or rejection. The copy node can also be used to send copy tasks in various ways, such as setting copy prerequisites and recipients, such as copying upon all approvals / rejections, or upon approval or rejection. Recipients can be direct superiors, department heads, role groups, user groups, designated members, or the submitter themselves (this is just one example). Processing nodes are mainly used for users to perform related business submission operations; rejection is not allowed at this node. Conditional branches can calculate the flow direction of the process based on different set conditions (this is also just one example).

[0045] Step S303: When execution reaches the current node with approver rules, determine the corresponding target group according to the approver rules.

[0046] Specifically, as shown in Figure 6, the approver rule is associated with at least one predefined group. The group is used to define a set of candidate approvers, such as role group, user group, business group and approval group. It can also include, but is not limited to, various approver options such as direct superior, direct department head, designated member, submitter, consecutive multi-level superiors, and contact person in the form. It can also support approval methods such as countersigning or signing, which is only an example.

[0047] Step S304: Based on the process form data and process context information, select all members who meet the preset conditions from the target group to form the actual approver set, and assign approval tasks to the members in the actual approver set so that the actual approvers can approve tasks based on the corresponding task approval permissions.

[0048] In one alternative implementation, when it is detected that the actual approver set is empty, or that a member of the actual approver set is the process initiator, the process automatically proceeds to the next node, or the approval task is assigned to a preset approver.

[0049] As shown in Figure 6, this embodiment of the invention also sets different approver rules. For example, when the approver is empty, options such as automatic approval, specifying a member, or transferring to the approval administrator can be set. When the approver and the submitter (initiator) are the same person, multiple options such as automatic skip, self-approval, transfer to the direct supervisor for approval, and transfer to the department head for approval can be set. These are just examples.

[0050] During the execution of the target process, if it is detected that the actual approver set is empty, or that a member of the actual approver set is the process initiator, the process can automatically move to the next node, or the approval task can be assigned to a preset approver.

[0051] This invention eliminates the risk of workflow interruption and ensures the continuity of process approval by triggering node flow or task reassignment through automated rules.

[0052] Specifically, the grouping includes at least role groups, user groups, business groups, and approval groups. Business groups are defined by logical expressions. Approval groups are associated with the process initiator and are pre-configured as approver paths with approval order. Based on process form data and process context information, all members meeting preset conditions are selected from the target group as the actual approver set. This includes: when the target group is a role group, selecting members whose jurisdiction matches the region information from the role group members based on the region information in the process context information to form the actual approver set; or, when the target group is a user group, determining all pre-configured members in the user group as the actual approver set; or, when the target group is a business group, substituting the field values ​​corresponding to the logical expression variables in the process form data into the logical expression of the business group for calculation to determine the actual approver set; or, when the target group is an approval group, matching the approval group and its corresponding approver path based on the initiator's identity corresponding to the target process, determining all users defined in the approver path as the actual approver set, and recording the corresponding approval order so that subsequent actual approvers can approve tasks based on the approval order.

[0053] This invention supports approval personnel management in different dimensions, namely role group management, user group management, business group management, and approval group management, which can more flexibly control the flow of process nodes. The above groups can be used for process definition approval personnel settings and condition flow judgment. Specifically, the set role groups are associated with regional jurisdiction attributes. Different users are added to different role groups, which can be used in process conditions and node approvals, as shown in Figure 7. When the process is executed, the actual set of approvers will be filtered according to the region where the initiator or processor is located. In actual application, when the initiator or the current approver is in the current role group, the members whose jurisdiction matches the regional information are filtered from the members of the role group based on the regional information of the process context. Generally, the members in a role group are all members of the same region. When the process node is executed to the current node, all members in the role group will receive the approval task.

[0054] The user group designed in this embodiment of the invention consists of a pre-configured, static set of users or departments. Different users and departments can be added to different user groups and can be used in process conditions and node approvers. As shown in Figure 8, when the initiator or the current approver is in a specified user group, all pre-configured members in the user group (all members belonging to the same department) can be determined as the actual set of approvers.

[0055] The business groups designed in this embodiment of the invention are defined through logical expressions. They can be pre-combined with different field data from the form, and corresponding control conditions can be edited. When the target group is a business group, the field values ​​corresponding to the logical expression variables in the process form data are substituted into the logical expression of the business group for calculation to determine the actual set of approvers, as shown in Figure 9. For example, (a != 1 && b>= 2) || c == 3 can be used in node approvers, where a, b, and c are words in the form, and A (day>=3) and B (day>3) are pre-configured. When the value of day is less than 3, only B will be found; when day is greater than or equal to 3, both A and B will be found. This is just an example. During process execution, the corresponding expression calculation results are parsed based on the field values ​​passed from the upstream service to control the rotation of process nodes (i.e., determining the actual set of approvers).

[0056] In this embodiment of the invention, the approval group is associated with the process initiator and pre-configured as an approver path with an approval order. That is, each user can set their own approval path, as shown in Figure 10. The users set in the approval path are in order, for example, A>B>C. This can be used in the node approvers. When the target group is an approval group, the corresponding approval group and its corresponding approver path can be matched based on the initiator of the target process. All users defined in the approver path are determined as the actual approver set, and the corresponding approval order is recorded so that the task can be approved in the current node according to the approver order. That is, after A is approved, it will go to B, and after C is approved, it will flow to the next node. This is just an example.

[0057] This invention uses four grouping categories—role group, user group, business group, and approval group—to accurately adapt to diverse business scenarios and comprehensively cover complex business functions. It also supports flexible expansion of grouping types and dynamic adjustment of filtering rules, enhancing the scalability of approver settings, adapting to dynamic business iteration needs, and enabling multi-dimensional linkage of approver allocation based on process context and historical process instances. This achieves complex and flexible approval logic requirements that traditional solutions cannot meet.

[0058] Step S305: After the approval task of the current node is completed, determine the next flow node based on the flow relationship between nodes and the process form data.

[0059] Specifically, step S305 includes: step S3051, when the process reaches the conditional branch node, obtaining multiple candidate branches associated with the conditional branch node and their respective configured condition judgment rules.

[0060] Step S3052: Based on the process form data, calculate the condition judgment rules for multiple candidate branches to obtain the calculation results.

[0061] Step S3053: If the calculation result indicates that only one candidate branch meets the condition, the node corresponding to the candidate branch that meets the condition is determined as the next flow node.

[0062] The nodes set in this embodiment of the invention also include conditional branches. When the process executes to a conditional branch, the flow direction of the process can be calculated according to different set conditions. This allows the acquisition of multiple candidate branches associated with the conditional branch and their respective configured condition judgment rules. For example, multiple candidate branches include branch A, branch B, and branch C, and the condition judgment rule corresponding to branch A is that the order amount is greater than 100,000 yuan, the condition judgment rule for branch B is that the order amount is greater than 50,000 yuan, and the condition judgment rule corresponding to branch C is that the project type is urgent, etc. This is just an example.

[0063] In this embodiment of the invention, when the process execution reaches a conditional branch node, multiple candidate branches associated with the conditional branch node and their respective configured condition judgment rules can be obtained. Then, based on the process form data of the current process instance (such as order amount, applicant information, project attributes, etc.), the data can be brought into the condition judgment rules of each candidate branch for logical calculation. The condition of each candidate branch is verified one by one, and the satisfaction / non-satisfaction calculation results of each branch are generated. If the calculation results show that only one candidate branch condition is satisfied, the candidate branch with satisfied condition can be directly determined as the next flow node of the process, and the process continues to execute along that branch.

[0064] In one optional implementation, if the calculation result indicates that the conditions of at least two candidate branches are met, the node corresponding to the candidate branch with the highest priority is determined as the next flow node according to the preset priority order of each candidate branch.

[0065] If the calculation result indicates that the condition of at least two candidate branches is met, the node corresponding to the candidate branch with the highest priority can be determined as the next flow node based on the preset priority order of each candidate branch. Each branch is executed in descending order of priority. The design method of the priority order of each branch is not limited. The priority order can be set by code development, or by dragging or manually selecting in the interface that displays the target flow logic structure. The default condition is that the priority cannot be adjusted, which is only an example.

[0066] In one optional implementation, if the calculation result indicates that the condition of no candidate branch is met, the node corresponding to the preset default branch is determined as the next flow node.

[0067] If the calculation result indicates that the condition of no candidate branch is met, the preset default branch rule can be triggered in this embodiment of the invention, and the node corresponding to the default branch can be determined as the next flow node. This is just an example.

[0068] This invention achieves automated flow of conditional branch nodes through rule calculation, result judgment, priority order, or default branch fallback logic. It not only ensures the accuracy of branch judgment, but also avoids process bottlenecks through priority and default branch mechanisms, adapting to complex branch flow scenarios.

[0069] In one optional implementation, in response to receiving an approval return instruction submitted by the approver of the current node, the approval task is returned to the first approval node for task approval, the first approval node being the approval node specified by the user in the approval return instruction; after the task approval is completed at the first approval node, the approval task is transferred to the current node.

[0070] As shown in Figure 11, this embodiment of the invention also includes the following features: when the process reaches the current node, the approver can transfer the task to a designated person for approval; whether signatures can be added / removed: this determines whether the approver can add other people to the approval process at the current node, or whether the approver can remove the added signatures after the task has been added; when the process reaches the current node, the approver can choose to roll back the current task to a designated approval node. After the rolled-back task is approved, it will skip the intermediate nodes and return to the current node to continue approval. Alternatively, when the node task is rolled back, the approver can return to the previous or first level when submitting again, making the process rollback function more flexible; as shown in Figure 12, this embodiment of the invention can also include the following features: when the email sending / email template function is disabled, the email notification function of this node will not be effective, and the email template of this node can be configured separately without going through the global email template configuration; the current node's workflow lifecycle can be defined, mainly for work order business; approval reminder / repeated reminder function: when the current node has not been approved, the next approval reminder time, reminder week, and reminder count can be set; trigger events Functionality: Different trigger events can be configured based on the current task status of the node. Callback types include, but are not limited to: HTTP calls, Spring built-in functions, SQL scripts, Groovy / JavaScript scripts, etc. As shown in Figure 13, this embodiment of the invention can also design a deduplication function for approvers: it judges whether the approvers are the same person when the process node flows, and distinguishes between consecutive and partially consecutive judgments. If multiple people approve a node, deduplication is not performed. Approval Administrator: When an approver cannot be found at a certain node, the current node can be transferred to the approval administrator for approval. Delegation Functionality: It works with the delegation information set in the process delegation menu for flow. If the current process does not support delegation, the current process cannot be selected within the delegation scope when setting the process delegation. As shown in Figure 14, when the node task flows to the delegator, the task will be delegated to the delegate for processing. Delegation Grouping Functionality: Different personnel can be delegated for approval based on different initiators. Validity Period: Within a specified range, it will be delegated to the corresponding delegate for processing. Delegation Scope: The current group needs to delegate the specified form, without limitation.

[0071] In one optional implementation, in response to receiving a target process adjustment instruction, the process definition data corresponding to the target process is obtained; the logical structure of the process definition is displayed through a visual interface, the logical structure including at least multiple nodes and the flow relationship between nodes; the user's modification operation on the logical structure is received; based on the modification operation, the modified process definition data is generated, and the modified process definition data is bound to the target process.

[0072] After responding to the user's target process adjustment instruction, this embodiment of the invention can obtain the process definition data corresponding to the target process and display the logical nodes of the process definition through a visual interface, as shown in Figure 15. The logical structure includes at least multiple nodes and the flow relationship between nodes. For example, different styles of graphic components are used to represent various types of nodes (such as rectangles representing approval nodes and diamonds representing conditional branches), and arrowed lines are used to represent the flow relationship between nodes. Flow conditions are marked, and the visual interface can also support operations such as interface scaling, drag-and-drop navigation, and node highlighting, making it convenient for users to view the complete structure of complex processes. This is just an example.

[0073] In this embodiment of the invention, users can modify the process logic structure through interactive controls on a visual interface, such as adding new nodes, deleting nodes, modifying connections between nodes, or double-clicking nodes to edit attributes, etc., without limitation. The user's modification operations can be captured in real time. After receiving the user's modification operation on the logic structure, modified process definition data can be generated based on the modification operation. After generating the process definition data, the legality of the modified process definition data can be verified, such as checking the closed loop of the node process and whether the required attributes are complete. After the verification is passed, the modified process definition data is bound to the target process, so that the target process initiated later can be directly executed based on the modified process definition data. This is only an example.

[0074] This invention transforms old process definitions into graphical logical structures through a visual interface, enabling users to modify processes with simple interactions, thereby lowering the threshold for process adjustment, shortening the process adjustment cycle, and improving operational convenience and iteration efficiency.

[0075] Furthermore, before binding the modified process definition data to the target process, the current status of the target process can be detected. When the target process is detected to be in the approval state, the modified process definition data is pre-stored; when the target process is detected to be approved, the modified process definition data is bound to the target process.

[0076] Before binding the modified process definition data to the target process, this embodiment of the invention can detect the current status of the target process. If the target process is currently in an unapproved state, the modified process definition data can be bound to the target process to update the corresponding process definition data in a timely manner. If the target process is in an approval state, a draft function is provided to store the modified process definition data. Editing and saving will not affect the currently executing process task. The modified process definition data can only be bound to the target process after the target process has been approved. Furthermore, this embodiment of the invention also supports comparing the currently modified logical structure with the currently bound version to intuitively present the differences in modification and reduce the risk of misoperation.

[0077] When the present invention detects that a process is in the approval stage, it can temporarily store the changes through a pre-storage mechanism to ensure that the ongoing approval process is not disturbed and to ensure the continuity of execution. After the approval is completed, the modified process definition data is automatically bound to the target process to achieve seamless connection and effect of the modified content and improve the efficiency of process iteration.

[0078] Furthermore, before binding the modified process definition data with the target process, the method also includes: inputting the preset process execution parameters and process form data into the modified process definition data, performing a simulation, and obtaining the simulation result; if the simulation result meets the preset process requirements, binding the modified process definition data with the target process; if the simulation result does not meet the preset process requirements, sending a prompt message indicating a process execution error to the user so that the user can adjust the process definition data.

[0079] As shown in Figure 16, in this embodiment of the invention, the generated modified process definition data can be used as process operations. During the sandbox simulation, all necessary execution parameters need to be provided. These execution parameters serve as the basis for process simulation and verification, and may include, but are not limited to, process execution parameters and process form data. Then, the preset process execution parameters and process form data can be input into the modified process definition data (including process definition, conditional rules, and approver rules) for sandbox simulation to obtain simulation results. This verifies the feasibility and effectiveness of the execution path, ensuring that all steps can be executed as expected and meet the predetermined goals. If the simulation results meet the preset process requirements, the modified process definition data will be approved, and then the modified process definition data will be bound to the target process for subsequent approval according to the modified process definition. If the simulation results do not meet the preset process requirements, a message indicating a process execution anomaly can be sent to the user. The prompt message indicates that users need to readjust the process definition data and repeat the simulation and verification until the verification result meets the process requirements. Then, the modified process definition can be bound to the target process. This is just an example. In this embodiment of the invention, multiple simulations can be initiated based on different form data during the sandbox simulation, simulating a real environment and demonstrating the interaction process of each step. This helps verify the rationality and operability of the process design. Furthermore, this embodiment of the invention can reference the current process architecture data and select different approvers for simulation, enabling early detection of process blockages caused by organizational changes or improper permission configurations. This makes the simulation environment highly similar to the production environment. Because sandbox simulation is a time-consuming function, the backend will execute the task asynchronously and supports concurrent operations, allowing the frontend to respond quickly without blocking other business operations. During task execution, the backend will push the current progress to the browser frontend in real time via a WebSocket connection. The pushed information includes: simulation completed, simulation failed, simulation progress, etc. After the task is completed, all data from the entire simulation process can be exported to an Excel file for offline analysis by users to promptly identify and troubleshoot incorrect approval paths. This is just an example.

[0080] This invention simulates the execution process through a sandbox simulation, which can avoid the risk of process ceiling in advance, ensure stable business operation, and support rapid repeated simulation, which can significantly shorten the process testing and optimization cycle and improve iteration efficiency.

[0081] In a specific embodiment, as shown in Figure 17, the present invention can predefine process forms, which are divided into custom forms and external forms. Custom forms are designed by dragging and dropping through a visual interface, while external forms are obtained by importing process form data developed from upstream systems and having users manually enter configuration field information. The process definition can bind form information, configure process conditions and approval nodes, and define a complete business process. When the process is executed, the corresponding process definition and bound process forms can be called to determine the approver of the flow node by judging the process condition branches and completing the process execution. For detailed explanation, please refer to the above embodiment, which will not be repeated here.

[0082] This embodiment also provides a workflow approval system, as shown in Figure 18. The system includes an access layer, a business layer, a data layer, and a runtime environment. The access layer includes, but is not limited to, interfaces such as PC, mobile, or mini-programs, supporting seamless integration across various platforms. The business layer consists of modules such as form design, process design, and a process engine to jointly manage process approval. The data layer is used for data caching and persistence to ensure data consistency and integrity. The runtime environment supports one-click deployment with Docker and is not limited by the server runtime environment; this is merely an example and not intended to be restrictive.

[0083] Figure 19 is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention.

[0084] Referring specifically to FIG19, a schematic diagram of a suitable electronic device for implementing embodiments of the present invention is shown below. The electronic device may include a processor (e.g., a central processing unit, a graphics processor, etc.) 1901, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1902 or a program loaded from memory 1908 into random access memory (RAM) 1903. The RAM 1903 also stores various programs and data required for the operation of the electronic device. The processor 1901, ROM 1902, and RAM 1903 are interconnected via bus 1904. An input / output (I / O) interface 1905 is also connected to bus 1904.

[0085] Typically, the following devices can be connected to the I / O interface 1905: input devices 1906 including, for example, a touchscreen, touchpad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, etc.; output devices 1907 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; memory 1908 including, for example, magnetic tape, hard disk, etc.; and communication devices 1909. Communication devices 1909 allow the electronic device to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 19 shows an electronic device with various devices, it should be understood that it is not required to implement or possess all the devices shown, and more or fewer devices may be implemented alternatively.

[0086] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 1909, or installed from a memory 1908, or installed from a ROM 1902. When the computer program is executed by the processor 1901, it performs the functions defined in the workflow approval method of the embodiments of the present invention.

[0087] The electronic device shown in Figure 19 is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of the present invention.

[0088] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium after being downloaded via a network. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium may also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the workflow approval method shown in the above embodiments is implemented.

[0089] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0090] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A workflow approval method, characterized in that, The method includes: in response to receiving a target process execution instruction, invoking a process definition and process form associated with the target process, wherein the process definition data includes at least multiple nodes, flow relationships between nodes, and approver rules configured for at least one node, the approver rules are associated with at least one predefined group, the group is used to define a set of candidate approvers, and the process form data includes at least task approval permissions configured for at least one node; based on the process definition, sequentially approving the nodes in the target process; when execution reaches the current node with an approver rule, determining the corresponding target group according to the approver rule; based on the process form data and process context information, filtering all members that meet preset conditions from the target group to form an actual approver set, and assigning approval tasks to the members in the actual approver set so that the actual approvers can perform task approval based on the corresponding task approval permissions; after the approval task at the current node is completed, determining the next flow node based on the flow relationships between nodes and the process form data.

2. The method according to claim 1, characterized in that, The process form is obtained through the following steps: in response to receiving a form customization instruction, a visual operation interface is provided to the user, the operation interface including a form component library and a form canvas area; The system receives user selection operations from the form component library and drag operations onto the form canvas area, renders the selected form component, and positions it at the corresponding position on the form canvas area; it receives user configuration operations for the current form component, the configuration operations including at least setting configuration data corresponding to the form component; it repeats the steps of receiving user selection operations from the form component library and drag operations onto the form canvas area until receiving user configuration operations for the current form component, until a custom process form is generated.

3. The method according to claim 1, characterized in that, The process form is obtained through the following steps: in response to receiving an external form association instruction, the external form data is called, and through the external form registration interface, the external form attribute information entered by the user is received. The external form data and external form attribute information are merged to obtain an external form, wherein the external form attribute information includes at least a form identifier, and the external form data has been developed by the upstream system; the external form is bound to at least one target process definition so that when an execution instruction is initiated for the target process, the external form is called through an interface based on the form identifier and the target process identifier, serving as the process form corresponding to the target process.

4. The method according to claim 1, characterized in that, The grouping includes at least role groups, user groups, business groups, and approval groups. Business groups are defined by logical expressions. Approval groups are associated with the process initiator and are pre-configured as approver paths with approval order. The step of filtering all members meeting preset conditions from the target group as the actual approver set based on the process form data and process context information includes: when the target group is a role group, filtering members whose jurisdiction matches the region information from the members of the role group based on the region information in the process context information to form the actual approver set; or, when the target group is a user group... When the target group is a business group, all pre-configured members in the user group are determined as the actual approver set. Alternatively, when the target group is an approval group, the field values ​​corresponding to the logical expression variables in the process form data are substituted into the logical expression of the business group for calculation to determine the actual approver set. Or, when the target group is an approval group, based on the initiator identity corresponding to the target process, the approval group related to the initiator and its corresponding approver path are matched, all users defined in the approver path are determined as the actual approver set, and the corresponding approval order is recorded so that subsequent actual approvers can approve tasks based on the approval order.

5. The method according to claim 1, characterized in that, The method further includes: in response to receiving a target process adjustment instruction, obtaining process definition data corresponding to the target process; displaying the logical structure of the process definition through a visual interface, the logical structure including at least multiple nodes and the flow relationship between nodes; receiving a user's modification operation on the logical structure; generating modified process definition data according to the modification operation, and binding the modified process definition data to the target process.

6. The method according to claim 5, characterized in that, Before binding the modified process definition data to the target process, the method further includes: pre-storing the modified process definition data when the target process is detected to be in an approval state; and binding the modified process definition data to the target process after the target process approval is detected.

7. The method according to claim 5, characterized in that, Before binding the modified process definition data to the target process, the method further includes: inputting preset process execution parameters and process form data into the modified process definition data, performing a simulation to obtain the simulation result; if the simulation result meets the preset process requirements, binding the modified process definition data to the target process; if the simulation result does not meet the preset process requirements, sending a prompt message indicating a process execution error to the user so that the user can adjust the process definition data.

8. The method according to claim 1, characterized in that, Based on the flow relationships between the nodes and the process form data, the next flow node is determined, including: when the process reaches a conditional branch node, obtaining multiple candidate branches associated with the conditional branch node and their respective configured condition judgment rules; calculating the condition judgment rules of the multiple candidate branches based on the process form data to obtain the calculation result; if the calculation result indicates that only one candidate branch's condition is met, determining the node corresponding to the candidate branch whose condition is met as the next flow node; if the calculation result indicates that at least two candidate branches' conditions are met, determining the node corresponding to the candidate branch with the highest priority as the next flow node according to the preset priority order of each candidate branch; if the calculation result indicates that no candidate branch's condition is met, determining the node corresponding to the preset default branch as the next flow node.

9. The method according to claim 1, characterized in that, The method further includes: when it is detected that the actual approver set is empty, or when a member in the actual approver set is the process initiator, automatically transferring to the next node, or assigning the approval task to a preset approver.

10. The method according to claim 1, characterized in that, The method further includes: in response to receiving an approval return instruction submitted by the approver of the current node, reverting the approval task to the first approval node for task approval, wherein the first approval node is the approval node specified by the user in the approval return instruction; after the task approval is completed at the first approval node, transferring the approval task to the current node.

Images