Add Assignee to Workflows

Purpose: 

The implementation of assignee in workflow feature enables you to associate a workflow task to a workflow rule, it is automatically assigned to the chosen user when the rule is triggered for records meeting the criteria specified in the workflow..The “assignee” is a main person who is responsible for the issue.

The reason for this implementation is because when there are multiple users sharing the same role (e.g. teachers), it creates a confusion to users on who to execute the actions thus by adding the assignee to workflows it enables and help to track the task that is assigned to them.

The following section will address the following features found in the Workflow.

Topics Covered:

• Conditions
• Types of Workflows
• Workbench
• Field Types [Steps]
  • Security Roles
  • Category
  • Editable Field
  • Deletable Field
• Field Types [Actions]
  • Workflow Step
  • Next Workflow Step
  • Comment Required
  • Allow by Assignee
  • Post Events

 

---

 

Conditions:
1. The list of assignees must be active in the school, when you configure in the security role.
(e.g. Security Role: Principal, there should be an existing Principal Role, and is assigned to a user in the Institution.)

2. The role of the position must be the same as the role allowed to access the workflow step
(e.g. I am the Principal, when I access the page, I will be able to view the Execute buttons else, I wont be able to view.)

3. Under Workflow > Actions, the Allow by Assignee must be selected.

Types of Workflows:

• School based Workflows
  • Surveys
  • Staff Leaves
  • Positions
  • Staff Change in Assignment

• Non-School based workflows
  • Training Courses
  • Training Sessions
  • Training Results

Workbench:

• Displays workflow item in the workbench only when the item is assigned to them, or if their role is System Administrator, or Super Users.
• If your Role is configured in the Security Role, there will be no notifications for Workflow appearing in the Workbench.

Field Type (Steps):

• For Part 1 (Security Roles) :
  • Security roles refers to System Roles that are able to assign to the assignee for the specific step of the record.
  • If Security Roles are not configured for the step ‘Open’ or the first step, the Assignee will be default set to the Creator.
  • 
  • 
  • If Security Roles is configured for the steps ‘Open’ or the first step, e.g. Principal, the Assignee will be default set to the Security Role, in this case the Principal.
  • 
  • 
  • If Security Roles are not configured for the steps after the ‘Open’ step or the second step onwards, the Assignee list will be empty as shown below.
  • 
  • Else, the list of possible assignees are retrieved based on the roles that are linked to the specific workflow step.
    • If the role for the workflow step is a staff position role, the list of assignees will be retrieved from the staff in the school.
    • 
    • 
    • If the role for the workflow step is not a staff position role, the list of assignees will be retrieved from the security groups that have access to that school.
    • 
    • 
  • If Security Role is configured, e.g. Principal, other roles will only be able to view and not able to execute actions.
    • Workflow – Security Role -> Principal
    • 
    • If Principal accesses the Open Status Position, able to view Execute Action buttons
    • 
    • If Teacher accesses the Open Status Position, unable to view as Security Role is not configured for the role of Teacher.
    • 

• For Part 2 (Category) :.
  • Indicates whether the record is editable/deletable in that specific step
  • Category represents the position of the step in its workflow.

• For Part 3(Editable) and 4(Deletable) :
  • Indicates whether the record is editable/deletable in that specific step
  • However, this is also dependent on the Security Role Permission. We have finalised the ability to perform action in the table below.
  • 

Scenario 1:
Role: Principal | Role Permission = YES | Workflow Permission = NO

Able to Edit = YES

Field Type (Actions):

• For Part 1 (Workflow Step) :
  • Workflow Step would represent the state of an item at a specific point in your workflow. An issue can be in only one status at a given point in time and it goes through a set of steps to reach a final step e.g. (Step 1: Open > Step 2: Pending for Approval > Step 3: Approved) or (Step 1: Open >  Step 2: Close.)

• For Part 2 (Next Workflow Step) :
  • Next Workflow Step refers to the next step after the particular action has been selected.
  • 
  • Once Submit for Approval action has been Selected, the next Workflow Step would be Pending for Approval.
  • 
  • 

• For Part 3 (Comment Required) :
  • If Comment is Required, is selected, the comment would be a mandatory field if the Action is performed.
  • 
  • 
  • However, if Comment Required is not selected, the field will not be mandatory.
  • 

• For Part 4 (Allow by Assignee) :
  • Allow by Assignee indicates if the Role that has not been configured in the Workflow Security Role, only the assignee will be able to execute Actions.
  • By default, Allow by Assignee should be Selected, if Security Role has been configured.
  • If Allow by Assignee is selected, Assignee will be able to execute the Actions.
    • For Example, Roles has not been configured for Open Status.
    • 
    • Allow by Assignee is selected, for Open Status.
    • 
    • When an Assignee logs in, they will be able to view the Execute Action buttons.
    • 
    • However, other users will not be able to view the Execute Action button.
    • 
  • If Allow by Assignee is not selected, Assignee will not be able to execute the Actions.
    • For Example, Roles has not been configured for Open Status.
    • 
    • Allow by Assignee is not selected, for Open Status.
    • 
    • When an Assignee logs in, they will not be able to view the Approve Action buttons.
    • 
• For Part 5 (Post Events) :
  • Currently, we have a Post Event, which is ‘Assign back to Creator’ when selected, this will assign it to the creator at a specific step.
  • For Example Staff Leave Workflow, we will set a Post Event for Assign Back to Creator at the Pending for Approval Step.
  • Which helps to shorthen the time for the Principal, to avoid searching for the Assignee in the list of Users, and just Select Approve.
  • 

Scenario A:

• If Staff is assigned to a unclosed workflow item, and staff has ended their assignment and the role has no other staffs, or role is removed from the security group. The unclosed Workflow item will be set as Unassigned.
• 
• It will auto-asign to to a staff, only when another staff has replaced the same position that has been assigned.

Scenario B:

• If Staff is assigned to a unclosed workflow item, and staff has ended their assignment and the role has other staffs, it will auto-assign to staff that joins the institution first.
• 
• We have ended Staff ‘Maria’ assignment in the Institution.
• 
• Auto-Assign to another Staff who shares the same role.