Step Three

In this step, the flow must fall to the administrator of the person who initiated the flow, after the "Proxy User" gives approval. Since this user's administrator will be dynamically assigned according to the user who started the flow, in the previous step, we put an Assignment object that will assign an administrator after the "Proxy User" step. After the Assignment object that will assign the manager, a Position object to which the manager will be assigned is placed in the flow.

In the Assignment object, to the Position object that we added second, we will assign the manager of the one who started the flow. Therefore, in the properties of the Assignment object;

• In the Target Object field, select which object in the stream to assign a value to. For our example, the object to select is the Position object that follows the assignment
• In the Resource Type field, the assignment type will be selected. Since we will assign administrators, the "User Manager" option is selected in this field
• Since we have selected administrator assignment as the source type, a field named Profile specific to this option will open. The Profile field selects which manager of the person's administrator profile will be used for the assignment.
• In the Selected Object field, the selection is made which object in the stream will be assigned a manager. According to the scenario, the user who started the flow will be assigned a manager. For position objects that are drag-and-drop from the toolbox into the flow, the default user is the Flow Initiator user. The position object to which the manager will be assigned also keeps the person who started the flow as a value when it is first added to the form, if no changes have been made. That is why in the "Selected Object" field we can make the selection of the same position object to which the manager will be assigned.

When the flow passes through the "Assign Manager" assignment object, the manager of the initiator of the flow will be assigned to the next position object.

The administrator will see the form filled out by the person requesting the permission and, if appropriate, approve the permission and advance the flow to the next step, and if not, reject it and send the flow back to the initiator of the flow.

First, the Document object to which the corresponding form is linked must be selected from the Document field in the object properties so that the administrator can see the completed form. The administrator should not be able to make any edits to the form that the initiator of the flow fills out. That's why we don't give editing authority for this position when attaching documents.

According to the scenario, the admin user needs to have "Confirm" and "Reject" action buttons. The events of a Position object positioned from the Toolbox to the flow screen by drag/drop are "Confirm" and "Reject" by default. If it had to have a different action depending on the scenario, this change would have been made from the "Events" field in the properties of the position object. We are not making any changes to this area because the events that come by default are in line with our scenario.

For all action descriptions attached to the position object, the object must be subtracted from the arrow for the corresponding action to indicate where the flow should be headed if the corresponding action occurs.

According to the scenario; If the manager approves the process by pressing the "Confirm" action button, the flow should be sent to the Human Resources Department as the next step. To route the process to all users in the Human Resources Department (multiple users) at the same time, the object that must be used in this step is the Position Group object. When the HR department is defined in a position group, the group will be automatically populated with how many users there are in that department.

That is, after the position object "Manager" we put in the flow a Position Group object in which we will populate the HR department users. We also link the "Confirm action arrow of the "Manager" position to this Position Group object.

Again, according to the scenario, if the "Administrator" object rejects the process by pressing the "Deny" action button, the flow will be sent back to the user who started the flow. Therefore, the "Deny" action arrow extracted from the "Administrator" object is bound to the Stream Initiator object.