Workflow Settings Table access permissions

In a workflow management system, the workflow engine is responsible for the flow of the process. First comb the business, transform the business into a workflow system of a business process, and then connect the various business links, so that the flow of business processes. There are many ways of circulation, such as sequential circulation, condition circulation, parallel circulation, cyclic execution and so on.

The process of the various aspects of the specific things to deal with, through the business form to complete. such as an approval flow, is divided into fill out the application form, review the application form, or even multilevel approval. Fill in the application is a business link, approval application is a business link (even a level of approval can do a business link). The details of the application form are completed in the form. Make a page entry form to fill out the application form, attach the path of this input form to the filling application form of the process, and make a form page for approving the application form and hang it to the approval link. Then you can run the approval flow by assigning the person to whom each link is executable.

A business process has several business processes there are several nodes, each node to deal with one thing, the processing of things done in the form, the form URL link to the node of the process, when the process runs to this node, open the form, until the user operation is completed, submitted to the next processing.

A business process, with multiple nodes, can hang a form on each node, and when associated with a business, typically adds a process instance ID field to the Business Main table. The business that is processed on each node can be associated with the process instance. The same form can be hung on each node of the process, or it can be a different form.

The form information processed on the nodes of the process is roughly the same, but with a small amount of difference, you can make a form, hang it on each node of the process, and control the different nodes to display different information through the permission settings. The advantage of this is that later forms maintain a time-saving effort, making a change that is not modified in every form. The downside is that when you start a form, you add the permissions to the Settings section.

Each node of a process is hung on the same form to display information by permission, or to hang multiple forms, depending on the business, if the business forms on each node are the same, set different permissions with the same form, and if each node does business differently, it hangs its own form.

If each node of the orchestration hangs the same form, in the process design, you can set the access rights for each field in the form by node. On the node of the process, set the table access permissions, set the access rights of the fields, is read-only, disabled, hidden, and so on. After Setup is complete, save the information in the orchestration's design file. When you run to this node, open this form, and when the table Form, remove the information that is saved in the design file, load it into the corresponding control on the page field, make the information or control read-only, hidden, or disabled, to achieve the operation permissions of the form.

If the workflow system integrates a smart form system, the settings for these operations permissions can be separated into smart forms to complete. On the form's controls, set different operation permissions for each node. It's a little simpler. You can set operation permissions by person, role, etc., or by node of the process.

Workflow Settings Table access permissions