Introduction

Approval requests are how position changes are reviewed and authorized. When a user needs to create a new position, modify an existing one, or request a replacement, they submit an approval request that follows your organization's workflow.

Submit an approval request

To create a new approval request, choose the type of change being requested and the position involved. Each approval request is routed through the workflow assigned to the relevant department. Scenario submission creates one approval request for each affected position. Promoting a scenario to the Operating Budget is a separate scenario-management action, not an approval request. The request type determines which approval workflow is used:

  • Position change: For new positions or changes to FTE, job code, adjustments, wage rate, or position parent (reporting relationship).

  • Replacement position: For replacing a currently approved position without changing its FTE, job code, or cost.

When submitting a request, all draft changes for that position are included. If your approval workflow requires file attachments, you will be prompted to upload them when creating the request. Users with the Override approval requests permission for the selected department may also see Approve immediately, which creates and approves the request without sending it through the standard workflow.

The request form includes a Request summary section that updates dynamically as you select positions. This section shows the total FTE change, cost change, and the approval workflow that will be used. Two tabs provide additional detail:

  • Approval steps: Shows the workflow steps, assigned approvers, and how many approvals are required at each step.
  • Selection criteria: Explains why the displayed workflow was selected. The workflow is based on the highest approval level required by the field changes, FTE impact, or cost impact.

Changes to fields set to No approval required take effect immediately when saved. Changes to fields assigned level 1 or higher create drafts that must go through approval.

Active position readiness

New positions must have enough information to calculate FTE and cost before they can become active. By the first date the position counts as active, it must have a name, active status, department, job code, schedule, and compensation source.

Position changes use the existing approved values plus the draft changes being requested. They do not need every position field to be changed again. If the change makes the position active, the position must have the information needed for FTE and cost calculations by that date.

For compensation, your organization's Position Base wage rate setting determines what is acceptable:

  • If Position Base wage rate is required, the position must have its own base wage rate effective by the active date.
  • If Position Base wage rate is optional, the position can use either its own base wage rate or an approved job code default wage rate effective by the active date. Default wage rates can be inherited from parent job codes.

If required information starts after the active date, the request is blocked so the position does not calculate with missing or partial values. The error message identifies the position, effective date, and missing information.

Position capacity for approval requests

New active positions consume paid subscription capacity when the approval request is submitted. At submission, FTE Tree checks whether enough subscribed position capacity remains and reserves that capacity for the request.

If the request is cancelled or denied, the reserved capacity is released. If the request is approved, the reserved capacity becomes part of the Operating Budget position count.

An approval request that already reserved capacity can finish even if your subscription is later reduced or another change puts the organization over capacity. In that case, future approval submissions, Operating Budget imports, or Operating Budget reactivations that would add active positions are blocked until capacity is available.

Position changes to existing Operating Budget positions and replacement requests do not require additional paid position capacity unless they create or restore an active Operating Budget position.

The approval process

Once submitted, an approval request progresses through the steps defined in the assigned workflow:

  1. Pending: The request is waiting for the first approver.
  2. In process: One or more steps have been reviewed and the request is progressing through the workflow.
  3. Approved: All required approval steps have been completed and the request is approved.
  4. Denied: An approver has denied the request.
  5. Cancelled: The request has been cancelled by the submitter or an administrator.

At each step, the assigned approver receives an email notification prompting them to review the request. Reminder emails are sent based on your organization's approval settings.

Pre-approval

If your organization has enabled pre-approvals, an approver may approve a request for a step that has not yet been reached in the workflow. This allows approvers who know they will need to sign off to do so ahead of time, speeding up the process.

Reassignment and delegation

If an approver is unavailable, use the option that matches the situation:

  • Per-request reassignment: A pending approval on a specific request can be reassigned from the request's Workflow tab. This is a one-time action for a single request and requires the Override approval requests permission for the request's department.

  • Approval delegation: An ongoing delegation can be created so that one user can approve all requests on behalf of another. Delegations can be permanent or temporary, and appear automatically in the delegate's Dashboard and approval lists. See Approval delegations for details on planned coverage and self-service delegation.

Note that delegation does not allow a user to approve their own request. If a delegate is also the requester, the delegated approval will not appear in their approval list and must be handled by another approver or through escalation.

Separation of duties

To maintain proper separation of duties, the person who submits an approval request cannot approve that same request through the normal workflow. This applies even if the requester is assigned as an approver through a workflow role or has been delegated approval authority by an assigned approver.

If the requester is the only available approver on a step, FTE Tree attempts to add backup approvers from the escalation role. Backup approvers count toward the original number of approvals required for that step; escalation does not increase the required approval count. If no backup approvers are available, the step is automatically approved and recorded in audit history.

Approver comments and response choices

When approving or denying a request, approvers can enter a comment explaining their decision. Depending on the workflow configuration, comments may be required for approvals, denials, or both. All comments are recorded as part of the request's audit trail.

If the workflow includes predefined response choices, approvers will also see a dropdown of reasons to select from when taking action. For example, approval reasons might include "Budget Verified" or "Within Headcount Plan", while denial reasons might include "Over Budget" or "Insufficient Justification". See Approval settings and workflows for details.

Request comments

Each approval request has a dedicated comments page where users can have threaded discussions about the request. Comments support replies and user mentions with email and in-app notifications. This is separate from the approve/deny comments described above and is intended for ongoing discussion about the request.

To access comments, click the Comments button on the request detail page. Commenting on approval requests requires the View position requests permission.

Override approvals

Users with the Override approval requests permission can immediately approve an approval request, bypassing all remaining workflow steps. This can be done from an existing request or, for eligible users, at request creation by using Approve immediately instead of Submit for approval. It is intended for time-sensitive situations where waiting for the normal workflow would cause operational delays, not for routine approvals. When a request is override-approved:

  • All remaining unapproved steps are cancelled.
  • The request is marked as approved by override.
  • The override is recorded in audit history.
  • Depending on your organization's settings, the overriding user may be required to provide a reason.

Override approval can also allow direct editing of position fields in the Operating Budget. When a user with the Override approval requests permission edits a field that normally requires approval, the change can take effect immediately without creating a draft. These direct edits are recorded in audit history.

If the request can still be reviewed by another approver, reassignment is usually preferred over override approval because it keeps the request in the normal workflow while documenting who changed the approver.

To review all override and self-approval activity, run the Self-approval activity report from Insights.

Auto-approval behavior

When the requester is the only available approver on a workflow step, the system follows a specific sequence to maintain separation of duties:

  1. Escalation attempt: If escalation is enabled and an escalation role is available, FTE Tree adds backup approvers from that role to the step. If backup approvers are found, the step proceeds normally using the original required approval count.

  2. Auto-approval: If no backup approvers are available (or escalation is disabled), the step is automatically approved on behalf of the requester and recorded in audit history.

  3. Daily limit: FTE Tree applies a limit of 5 auto-approvals per user in a rolling 24-hour period. When the limit is reached, further auto-approvals are paused and the organization owner is notified. Contact FTE Tree support if your organization needs a different limit.

To minimize auto-approvals, administrators should:

  • Enable escalation in Approval settings.
  • Assign escalation roles on each organization approval role.
  • Ensure each workflow step has multiple approvers assigned.

Cancel a request

The submitter or an administrator may cancel an approval request at any time before it is fully approved. Depending on the workflow configuration, a comment may be required when cancelling.

Restart a request

If an approval request has been denied or cancelled, it can be restarted. Restarting creates a new approval request connected to the original and includes the same position changes. The original request remains unchanged for history and review.

The new request uses the workflow currently assigned to the department, which may differ from the original if workflow settings have changed. The approval process begins from the start.

To restart a request, navigate to the denied or cancelled request's detail page and click Restart approval. Restarting requires the Create position requests permission for the request's department.

Track your requests

The Dashboard provides quick access to:

  • Requests you have submitted and their status.
  • Requests that are awaiting your approval.
  • The number of active and upcoming approval tasks assigned to you.

Every interaction in the approval process is timestamped and documented, providing a complete audit trail of who took what action and when.

Position parent changes

Approval requests can include changes to a position's parent, which defines the reporting relationship in the org chart. When a parent change is approved, the system applies the new parent to the position and updates the organizational hierarchy.

Before applying a parent change, FTE Tree checks that the change will not create a circular reporting relationship. For example, a position cannot become a child of one of its own descendants. If the hierarchy has changed since the request was originally submitted and the parent change would now create that issue, the change is blocked. In this case, the requester receives a Dashboard message explaining why the parent change could not be applied. The requester can then review the latest hierarchy and submit a new parent change request if needed.

Need help?

If you have questions about the approval process, please contact us or email us at support@ftetree.com.