Setting Supervisor Approval Requirements of Employee-Submitted Transactions

Issues: Employees should be able to submit certain requests without them needing to be approved by a supervisor--or requests should require the approval of a supervisor.

Troubleshooting Tips:

Depending on authorization roles, employees may be able to add, edit, and/or delete transactions without needing to have the transaction approved by a supervisor. This authorization is set in the related transaction screen under the Employee Section in the Authorization Policy Hierarchy tree.

If users do not have the required authorization level for requests:

• The user can be assigned to another role with the required authorization access. More About Adding An Employee Role
  • To find which roles provide the required authorization capabilities, run the Authorization Control report, found in the Reports section>System card.
  • Assign the appropriate role to the employee through the Employee record>Roles screen. See the instructions on Steps for Adding an Employee-Level Role.
• An existing non-standard role can be updated to grant the required access. More About Updating an Existing Role
  • Remember that any changes to a role will update the access for ALL employees assigned to that same role.
  • Standard roles cannot be edited--a new role must be created and modified.

• A new role can be created which has the required access and assigned to the user. More About Creating New Roles

  New roles can be created by adding a role or by replicating an existing role that has most of the required attributes, and then modifying it to change the access.

  • For more information on creating a new role, see Steps for Creating a New Role.
  • A replicated role can also be replicated again, and modified to create another role with different attributes. For more information on replicated roles, see Steps for Replicating a Role.

Setting the Transaction Request Status:

In the example below, the Employee Calendar screen is being set for users to be able to read, edit, and delete existing request records without supervisor approval. New requests must be approved by the supervisor.

1. From the Configuration section>System card>Role screen, open the record to be updated, or create a new role.
2. Click on the Authorization Controls button in the left pane.
3. Expand the folders in the Authorization Policy Hierarchy to find the screen or policy to be updated. Note: In order to access a specific screen, the user must grant access to each of the levels above the selected screen. In the example below, the users are first given access to the Employee Section and then the Employee TCS Card, and finally the Employee Transaction policy screen. More About Setting up Access to Parent Structure Levels

   The steps to set up the access to parent structure levels are as follows:

   1. From the Configuration section>System card>Roles screen, locate and open the Role record to update.
   2. Select the Authorization Controls button in the left pane to access the Authorization Policy Hierarchy tree.
   3. In the Authorization Policy Hierarchy tree, highlight the Root level. The Section options are displayed in the right pane.
   4. For the parent Section record, click on the Add button to add this policy to the role. The button action is changed to Remove. In the example below, the Configuration Section is made accessible to this role.

      

   5. In the Authorization Policy Hierarchy tree in the left pane, highlight the parent Section option. The related Card options are displayed in the right pane.
   6. For the parent Card record, click on the Add button to add access to this card to the role. The button is changed to Remove. In the example below, the Assignments Card is made accessible to users in this role.

      

   7. In the Authorization Policy Hierarchy tree, highlight the parent Card of the policy to be viewed. The related Screen options are displayed in the right pane.
   8. For the parent Screen record, click on the Add button to add access to this card to the role. The button is changed to Remove. In the example below, the Holiday screen is made accessible to users in this role.

      

4. The transaction policies are then available to set up by selecting the Add button to the left of the record. Clicking on this button alternately adds and removes the policy.
5. Open the policy record by clicking the card arrow on the record.

   

6. For each request type, indicate if the employee should have the ability to Create, Edit, and/or Delete a transaction without it needing to go through a request queue for supervisor approval.
   • More About Create/Create Request Access

     When an employee has Create Request access: 

     • The transaction is created as a Request and must be approved through the Actions Section>Approval card>Transaction Requests screen.
     • The Reason field is enabled but not required. When a request with a reason is approved, the reason is copied to a Transaction Note with a subject of Reason.
     • Once the transaction has been approved, the transaction is displayed on the Transaction screen and various request screens with the appropriate Request to Create icon.

     When an employee has Create access:

     • The transaction is created as a Transaction and not treated as a Request; it does not need to go through the approval process.
     • The Reason field is disabled.
     • The transaction is displayed in the Transaction screens with the related transaction icon.

   • More About Delete/Delete Request Access

     When an employee has Delete Request access: 

     • A Request to Delete is created and must be approved through the Actions Section>Approval card>Transaction Requests screen.
     • The Reason field is enabled but not required. When a request with a reason is approved, the reason is copied to a Transaction Note with a subject of Reason.
     • The transaction is displayed on the Transaction screen and various request screens with the related Request to Delete icon.
     • Once the transaction request has been approved by a supervisor, the transaction is removed from all screens.

     When an employee has Delete access:

     • The entry is created as a Transaction and not treated as a Request; it does not need to go through the approval process.
     • The Reason field is disabled.
     • Once the record is saved, the transaction is removed from all screens.
   • More About Edit/Edit Request Access

     When an employee has Edit Request access: 

     • A Request for Edit is created and must be approved through the Actions Section>Approval card>Transaction Requests screen.
     • The Reason field is enabled but not required. When a request with a reason is approved, the reason is copied to a Transaction Note with a subject of Reason.
     • The transaction is displayed on the Transaction screen and various request screens with the appropriate Edit Request icon.

     When an employee has Edit access:

     • The edit is created as a Transaction and not treated as a Request; it does not need to go through the approval process.
     • The Reason field is disabled.
     • The transaction information is updated when the record is saved, and the appropriate icon is displayed on the Transaction screen.
7. When finished setting up each field, Save the record.