Configuring approvers for a user

In absentify, all leave requests must be approved by a designated approver. Approver settings allow for flexibility by offering various options, including department managers, synchronized Microsoft managers, or custom approvers.

---

​

Approver configuration options

There are four main ways to configure approvers for an employee:

​

1. Department-based approvers

By default, a user’s approver is the manager of their assigned department.

• How it works:
  • Select the specific department whose managers should act as the approvers for the employee.
  • The managers of the chosen department automatically become the approvers for the user.
• Approval processes:
  Approval processes are defined at the department level.
• Automatic updates:
  If the department manager changes, the approvers for all users linked to that department are updated automatically.

​

2. Microsoft profile synchronization

This option uses the manager defined in the user’s Microsoft profile as their approver.

• How it works:
  • The Manager field in the user’s Microsoft profile is synced automatically.
  • Changes to the manager in Microsoft will reflect in absentify during the next sync.
• Multi-level approvers:
  You can configure up to five levels of approvers:
  • First-level approver: The direct manager of the employee.
  • Second-level approver: The manager of the first-level approver.
  • Additional levels are added by tracing the management hierarchy in the Microsoft profile.
• Approval processes:
  Options for approval flows:
  • Linear - All must agree
    Approvers are contacted consecutively. If any approver denies the request, the process stops, and the request is marked as denied.
  • Linear - One must agree
    Approvers are contacted consecutively. If any approver approves the request, the process stops, and the request is marked as approved.
  • Parallel - All must agree
    All approvers are contacted simultaneously. If any approver denies the request, it will not be approved.
  • Parallel - One must agree
    All approvers are contacted simultaneously. If any approver approves the request, it will be approved.

​

3. Custom approvers

Use this option to manually define approvers for the employee.

• How it works:
  • Select one or more approvers, regardless of department or Microsoft profile settings.
  • This option is ideal for unique workflows requiring specific approvers.
• Approval processes:
  Custom approvers support all approval flows:
  • Linear - All must agree
    Approvers are contacted consecutively. If any approver denies the request, the process stops.
  • Linear - One must agree
    Approvers are contacted consecutively. If any approver approves the request, the process stops.
  • Parallel - All must agree
    All approvers are contacted simultaneously. If any approver denies the request, it will not be approved.
  • Parallel - One must agree
    All approvers are contacted simultaneously. If any approver approves the request, it will be approved.

​

4. No approver

Use this option if no approval is required for the employee’s leave requests.

• How it works:
  • Requests are automatically approved without the need for an approver.

---

​

Detailed approval processes

The way leave requests are routed and approved depends on the selected approval process. Here’s a breakdown of each option:

​

Linear approval processes

1. Linear - All must agree
   • How it works: Approvers are contacted one at a time, in the order they are listed. If any approver denies the request, it will not proceed further and is marked as denied.
   • Example:
     Approver A → Approver B → Approver C
     • Approver A approves → request moves to Approver B.
     • Approver B denies → request is denied, and Approver C is not contacted.
2. Linear - One must agree
   • How it works: Approvers are contacted one at a time, in sequence. If any approver approves the request, the process stops, and the request is marked as approved.
   • Example:
     Approver A → Approver B → Approver C
     • Approver A denies → request moves to Approver B.
     • Approver B approves → request is approved, and Approver C is not contacted.

​

Parallel approval processes

1. Parallel - All must agree
   • How it works: All approvers are notified at the same time. If any approver denies the request, it is immediately marked as denied.
   • Example:
     Approvers A, B, and C are notified simultaneously.
     • Approver A approves, Approver B approves, but Approver C denies → request is denied.
2. Parallel - One must agree
   • How it works: All approvers are notified at the same time. If any approver approves the request, it is immediately marked as approved.
   • Example:
     Approvers A, B, and C are notified simultaneously.
     • Approver A denies, Approver B denies, but Approver C approves → request is approved.

---

​

Additional features

​

Approval notifications

• A notification is sent to the requestor at every status change of their leave request.
• Notifications are sent for each approver’s decision unless the request status is finalized (approved or denied).

​

Admin and manager permissions

Admins and department managers can approve or deny requests even if they are not the designated approvers:

• Admins: Can act on any leave request within the company.
• Department managers: Can approve or deny requests for users within their department.

​

Approver-override for admin-submitted requests

When an admin submits a leave request on behalf of a user, a dropdown may appear to override the standard approval workflow.
This gives the admin the option to immediately approve a request, rather than relying on the default assignment defined by the approval rule for that user or department. Best practices for using the override:

• Use only when necessary: Stick to the default approver configuration whenever possible to maintain consistency.
• Communicate overrides: If you override the default approver, inform both the original and selected approver to avoid confusion.
• Document decisions: In sensitive or exceptional cases, consider noting why an override was made (e.g. via internal policy or comments).
• Review regularly: If overrides are frequently needed, it might indicate that the approval rules need to be updated.

When the dropdown is hidden: The dropdown is only shown when an override is meaningful and permitted based on the approval logic. The visibility of the approver dropdown follows these conditions:

• Linear_all_have_to_agree: The dropdown is hidden when there is only one approver, and that approver is the current admin.
  There are no other approvers to choose from, so overriding is not applicable.
• Linear_one_has_to_agree: The dropdown is hidden when the first approver in the list is the current admin.
  The admin already fulfills the role of approver, so there is no need for selection.
• Parallel_one_has_to_agree: The dropdown is hidden when the current admin is part of the parallel approver group.
  Any approver in the group can approve, so selection is not necessary.
• Parallel_all_have_to_agree: The dropdown is hidden when there is only one approver, and that person is the current admin.
  As all defined approvers must approve the request, there is no room for override.

This behavior ensures the override option is only presented when it is meaningful and applicable to the approval process.

---

​

Tips for approver settings

• Department-based approvers are dynamic: Automatically update with changes to department managers.
• Microsoft synchronization reduces manual effort: Ensures managers stay up-to-date across platforms.
• Custom approvers allow flexibility: Ideal for workflows requiring specific approvers or additional oversight.
• No approver simplifies workflows: Use this option for self-managed leave requests.