Approval settings and workflows

Introduction

Approval workflows help your organization review position changes before they become part of the Operating Budget. You can route requests to the right approvers based on department, request type, approval level, FTE impact, or cost impact.

Your organization can create workflows for different departments and levels of review. FTE Tree tracks each request, records who acted on it, and keeps the approval history available for review.

General approval settings

Reminder email settings

• Reminder email days: Sets the number of days between reminder emails sent to approvers. For example, if the first request email is sent on Monday and this value is set to 3, a reminder will be sent 72 hours later on Thursday. Defaults to 3.

• Reminder email total: Limits the total number of emails sent to a user when they are an approver. Includes the first email and reminders. A value of 0 means no emails will be sent. This value is checked each time an approval request is reviewed, so changes take effect immediately. Defaults to 5.

• Reminder email days back-off: Increases the delay between each consecutive reminder email. The value is compounding. For example, with a 3-day reminder interval and a 1-day back-off, reminders will be sent on days 3, 7, and 12. Defaults to 1.

• Reminder email business days only: Counts only business days (Monday through Friday) between reminder emails. Holidays are not excluded. Disable this option to use calendar days. Defaults to True.

Approval behavior settings

• Allow pre-approvals: When enabled, allows a user to pre-approve an upcoming request in a step that has not yet been started. When disabled, all previous approval steps must be completed first in sequential order.

• Require comment when approving request: When enabled, requires an approver to enter a comment or note when approving a request. Defaults to False.

• Require comment when denying request: When enabled, requires an approver to enter a comment or note when denying a request. Defaults to True.

• Active organization user approvers: When enabled, only active organization users will be included in newly created approval requests. If the inactive user is the only approver in a step, it may result in an auto-approval. Defaults to False to minimize auto-approval risk.

Default approval levels

• Default approval level - replacement: Sets the approval level used for all position replacement requests. Since replacement requests do not involve field changes, a fixed level is used organization-wide rather than being calculated from the request. This must be set before users can submit replacement requests.

• Default approval level - elimination: Sets the approval level used for all position elimination requests. Since elimination requests do not involve field changes, a fixed level is used organization-wide rather than being calculated from the request. This must be set before users can submit elimination requests.

Request numbering

• Prefix for request label: Attaches a prefix when a request number is displayed. Defaults to "APR-". The hyphen is part of the prefix, so you can remove it by changing the prefix to "APR" or leave the prefix blank.

• Number of digits to pad for request numbers: Pads the sequential request number to a specified number of digits. With the default prefix and a padding of 4, request #134 displays as "APR-0134". Set to 0 for no padding. If the number of requests exceeds your setting, this value will be automatically updated unless set to 0.

Escalation settings

Escalation automatically adds backup approvers when an approval step has been waiting longer than your organization allows. When escalation happens, users assigned to the escalation role are added to the step and notified by email.

• Enable escalation: Enables automatic escalation of approval requests after timeout. Defaults to False.

• Escalation days: The number of days without action before escalation is triggered. Measured from the earliest email sent in the active step. Defaults to 7.

• Escalation business days only: Counts only business days (Monday through Friday) for the escalation timeout. Holidays are not excluded. Disable this option to use calendar days. Defaults to True.

Escalation happens at most once per approval step. If no backup approvers are available, the step continues without adding anyone.

Backup approvers count toward the original number of approvals required for the step. For example, if the workflow required all two original approvers and escalation adds a backup approver, two total approvals from eligible original or backup approvers complete the step. Denials still count against the step's configured denial limit.

Escalation also happens immediately when the requester is the only approver on a step. This helps preserve separation of duties by looking for another reviewer. If no backup approver is available, the step is automatically approved and recorded in audit history.

Auto-approval daily limit

• Auto-approval daily limit: FTE Tree applies a safety limit of 5 auto-approvals per user in a rolling 24-hour period. When a user reaches this limit, further auto-approvals are paused and the organization owner receives a Dashboard notification. This helps catch misconfigured workflows where a single user is repeatedly the only approver. Contact FTE Tree support if your organization needs a different limit.

Configure for separation of duties

To minimize the risk of changes being approved without independent review:

1. Enable escalation and set an appropriate escalation timeout.

2. Assign escalation roles to each organization approval role so that backup approvers are always available.

3. Ensure each workflow step has multiple approvers. If only one user is assigned to a step and that user submits a request, the step will auto-approve unless backup approvers can be found.

4. Understand the auto-approval daily limit so repeated auto-approvals are caught by the FTE Tree safety limit.

5. Review the self-approval activity report periodically to monitor all bypass activity.

Users with the Override approval requests permission may be able to approve urgent requests immediately or make certain Operating Budget edits directly. If a direct edit exceeds your organization's FTE or cost impact rules, the user must submit it through an approval request instead. See Permissions and roles for best practices on granting override access.

Types of approval workflows

Approval workflows are categorized based on the type of position request being made:

• Position change: This type of request is made when changes are made to an existing position's fields such as FTE amount, job code, pay adjustments, or wage rate. Any change to the position's FTE or cost will require an associated Position Change approval workflow to be assigned. If the department is part of the change request, it will be routed to the approval workflow associated with the new department. The approval level is determined by the highest-level field included in the request.

• New position: This type of request is made when a brand new position is being created. All required position fields must be provided on the request. The approval level is determined by the highest-level field included in the request.

• Replacement position: When a user wishes to replace a currently approved position without making any changes to that position's FTE, job code, or cost, they may request routing through a Replacement Position workflow. This type is typically used for a replacement position opening when someone leaves your organization or takes another position. The approval level is set at the organization level in the general approval settings.

• Position elimination: When a user wishes to eliminate an approved position, they may request routing through a Position Elimination workflow. The approval level is set at the organization level in the general approval settings.

Approval levels

Approval levels provide a tiered system for routing requests through different workflows based on the significance of the changes being made. Higher levels represent more significant changes and can require more rigorous approval processes.

How approval levels work

Each approval level has a numeric display order and a name. Approval levels start at 1. For example, an organization might create three levels:

Fields set to No approval required take effect immediately when saved without creating a draft or requiring an approval request. Fields assigned approval level 1 or higher create draft changes that require an approval request.

Approval levels connect two parts of the system:

1. Position fields are each assigned either No approval required or an approval level where approval routing applies. This determines how significant a change to that field is considered. Fields set to No approval required auto-approve on save. Fields at level 1 and above create draft changes that require an approval request.

2. Approval workflows are each assigned an approval level. This determines which tier of changes the workflow is designed to handle.

How approval levels route requests

When a user submits a position change or new position request, FTE Tree reviews the fields being changed and uses the highest approval level required by those fields. It then routes the request to a workflow assigned to the relevant department that can handle that level of review.

For example, if a request changes a field that requires "Standard" approval but no "Standard" workflow is assigned to the department, FTE Tree will automatically route the request to the next available workflow, such as an "Elevated" workflow. This ensures that requests always receive at least the required level of scrutiny.

For replacement and elimination requests, the approval level does not depend on field changes. Instead, a fixed default level is configured in the general approval settings and used for all requests of that type.

Approval routing also depends on whether the position has enough information to calculate FTE and cost. New active positions must have the required department, job code, schedule, and compensation information before they can be submitted. If required information is missing, the request is blocked with a message explaining what must be fixed.

Manage approval levels

Approval levels are managed from the approval settings area in Settings > approval requests. Each level requires:

• Display order: A numeric value that determines the level's position in the hierarchy. Lower numbers represent less significant changes.
• Level name: A descriptive name for the level (e.g., "Standard", "Elevated", "Executive").

Both the display order and level name must be unique within your organization. An approval level cannot be deleted if it is currently referenced by any fields, workflows, or organization default settings.

Schedule field and FTE impact

The approval level assigned to the Schedule field applies to all schedule changes uniformly. However, not all schedule changes have the same business impact. A schedule reconfiguration that does not change FTE is very different from one that increases headcount.

To route schedule changes based on their actual FTE impact, configure FTE impact levels. FTE impact levels supplement the Schedule field's approval level: the higher of the two always applies. This means you can set the Schedule field to a lower base approval level and let FTE impact thresholds escalate when the change is more significant.

If the Schedule field is set to No approval required and no FTE or cost impact rules apply, schedule changes take effect when saved. If FTE or cost impact rules apply, a schedule change may still require approval when it changes the position's FTE or cost. FTE Tree always uses the highest approval level required by the change.

FTE impact levels

FTE impact levels let your organization require more review when a schedule change meaningfully changes FTE. This is useful when some schedule edits are routine but larger FTE changes need higher-level approval.

How FTE impact levels work

When a schedule change is included in an approval request, FTE Tree compares the proposed FTE with the current Operating Budget FTE. The change is grouped into one of three impact types:

• Net-zero FTE change: The schedule was modified, but the resulting FTE did not change. For example, switching from a Monday-Friday 8:00-5:00 schedule to a Monday-Thursday 8:00-6:15 schedule with the same weekly hours.

• FTE increase: The schedule change resulted in a higher FTE. For example, changing from a 20-hour/week schedule to a 40-hour/week schedule.

• FTE decrease: The schedule change resulted in a lower FTE. For example, reducing from a full-time to a part-time schedule.

Threshold bands

FTE increase and FTE decrease rules can use more than one threshold. This lets small changes follow one approval level while larger changes require a higher level.

When a position meets more than one threshold, FTE Tree uses the highest matching approval level.

Net-zero FTE changes can have one approval rule.

For example:

In this configuration, a small FTE increase (0.01 to 0.99 FTE) requires "Elevated" approval, while a large increase (1.0 FTE or more) matches the higher 1.0 threshold and requires "Executive" approval. A net-zero schedule change only requires "Standard" approval.

Interaction with field approval levels

FTE impact levels supplement, but never replace, the approval levels set on individual fields. When a request is submitted, FTE Tree considers:

1. The highest field-based approval level (from the changed fields)
2. The highest FTE impact-based approval level (from FTE threshold configuration)
3. The highest cost impact-based approval level (from cost threshold configuration, see Cost impact levels)

The final approval level is the highest of the applicable levels. FTE and cost impact rules can increase the required approval, but they cannot reduce the approval required by a field. If no impact thresholds are set, these rules do not affect routing.

Per-position evaluation

When a request includes multiple positions, each position is reviewed separately. The position that requires the highest approval level determines the request's overall level. This prevents increases and decreases on different positions from hiding each other.

Approval level details

Every approval request shows how its approval level was selected. The detail explains whether the level came from field settings, FTE impact, cost impact, or a combination of those rules.

The request form also shows these details before submission. The Selection criteria tab in the Request summary section updates as positions are selected, so users can see why a request will follow a particular workflow.

Manage FTE impact thresholds

FTE impact thresholds are managed from Settings > approval requests > FTE impact tab on the Impact Levels page. Each threshold requires:

• Impact type: Whether this threshold applies to net-zero, increase, or decrease changes.

• Minimum FTE change: The minimum FTE change for this rule to apply. For decrease thresholds, enter a positive number representing the size of the decrease. For example, enter 0.5 to match a decrease of 0.5 FTE or more.

• Approval level: The approval level required when the threshold is matched.

If no thresholds are set, FTE impact has no effect on approval routing.

Cost impact levels

Cost impact levels work like FTE impact levels, but they use the dollar cost change instead of the FTE change. This allows your organization to require higher approval for changes with a significant financial impact, even when FTE does not change.

How cost impact levels work

FTE Tree compares the proposed annual cost with the current Operating Budget annual cost. This includes wage rates, FTE-based calculations, and annual adjustments.

The change is classified into one of three impact types:

• Net-zero cost change: Fields were modified but the resulting cost did not change.

• Cost increase: The change resulted in a higher annual cost.

• Cost decrease: The change resulted in a lower annual cost.

Threshold bands and interaction

Cost impact rules work the same way as FTE impact rules. Increases and decreases can have multiple thresholds with higher approval levels for larger changes. Net-zero cost changes can have one approval rule.

When a request is submitted, FTE Tree considers:

1. The highest field-based approval level
2. The highest FTE impact-based approval level
3. The highest cost impact-based approval level

The final approval level is the highest applicable level. FTE and cost impact rules can increase the required approval, but they cannot reduce it.

Manage cost impact thresholds

Cost impact thresholds are managed from Settings > approval requests > cost impact on the Impact levels page. FTE and cost impact thresholds are managed on the same page using separate tabs. Each threshold requires:

• Impact type: Whether this threshold applies to net-zero, increase, or decrease changes.

• Minimum cost change: The minimum cost change for this threshold to apply. For decrease thresholds, enter a positive number representing the size of the decrease. For example, enter 5000 to match a cost decrease of $5,000 or more.

• Approval level: The approval level required when the threshold is matched.

If no thresholds are configured, cost impact has no effect on approval routing.

Workflow steps

Each approval workflow consists of one or more steps that define who needs to approve a request and in what order. Steps are processed sequentially, and each step can be assigned to:

• Specific users: Individual organization users assigned as approvers.
• Approval roles: Dynamic roles that are mapped to users by department, allowing the correct approver to be selected automatically based on the department in the request. See Permissions and roles for more information on setting up approval roles.

Each step also has the following settings:

• Step name: A label describing the purpose of the step (e.g., "Manager Review", "Finance Approval").

• Approvers required: The number of listed approvers required to approve before the step is marked as approved. Set to a specific number for partial approval (e.g., 2 of 5 assigned approvers), or leave blank to require all assigned approvers. If fewer approvers are assigned to the step than the number specified, all assigned approvers will be required.

• Allowed denial count: The number of denials allowed before the step is automatically denied. Defaults to 0, meaning any denial will deny the step.

If a step has no roles or users assigned, it will auto-approve. Similarly, if a workflow has no steps at all, requests using that workflow will auto-approve. A step will also auto-approve if the requester is the only assigned approver and no escalation approvers are available, to maintain separation of duties.

When a request is created, its approval path is saved with the request. Changes to the workflow after that point do not affect requests that are already in progress.

Auto-approve workflows

A workflow with no approval steps will automatically approve any request routed to it. This is displayed on the workflow detail page with an "Auto-Approve" badge. Auto-approve workflows are useful for:

• Replacement and elimination requests at a configured approval level that should be tracked but processed without manual review.

• Low-impact changes where organizational policy allows automatic approval but you still want the request tracked in the approval history.

To set up an auto-approve workflow, create a workflow at the desired approval level and do not add any approval steps. When a request matches this workflow, it will be immediately approved and the requester will be notified. Auto-approved requests follow the same post-approval processing as manually approved requests, including creating openings when applicable.

Workflow comment and response settings

Each approval workflow can have its own comment requirements and response choices. These settings control what approvers see and what they must provide when they approve, deny, or cancel a request.

Comment requirements

• Require comment when approving: When enabled, the approver must enter a comment when approving a request routed through this workflow. Defaults to False.

• Require comment when denying: When enabled, the approver must enter a comment when denying a request. Defaults to True.

• Require comment when cancelling: When enabled, a comment is required when cancelling a request. Defaults to True.

Approval response option sets

Workflows can optionally provide approvers with a dropdown of predefined reasons when taking action on a request. This standardizes approval and denial reasons across your organization.

• Approve response option set: An optional option set displayed to the approver when approving a request. For example, options might include "Budget Verified", "Within Headcount Plan", or "Executive Approved".

• Deny response option set: An optional option set displayed to the approver when denying a request. For example, options might include "Over Budget", "Insufficient Justification", or "Position Freeze".

Response choices are managed from the workflow response settings. Each workflow can use a different set of options, allowing you to tailor the approval experience for different parts of your organization.

Approval workflow attachments

Approval workflows can require or allow file attachments on new requests. Attachments are useful when approvers need supporting documents before making a decision.

Each approval workflow file attachment requires:

• Attachment title: A clear description displayed instead of the actual file name.

• Required upload: When enabled, the user must upload a file for this attachment when submitting the request. When disabled, the file upload is optional.

• File instructions: Optional instructions explaining how to use the file.

• Display on new request: Enable to show the attachment on new requests. Disabling does not retroactively remove it from existing requests.

All files within FTE Tree are encrypted in transit and at rest. Download links are time-limited to 15 minutes and restricted to authorized users. For additional details, see Audit events.

Assign workflows to departments

Approval workflows are assigned through the department tree and can apply to child departments. You can assign a workflow to the top of your department tree and let it apply to all child departments, or assign specific workflows to specific departments or branches. A department must have an approval workflow before users can make approval requests for that department.

When assigning workflows to departments, the workflow's approval level determines which requests it handles. A department can have multiple workflows of the same request type assigned at different approval levels, allowing different tiers of changes to follow different approval processes.

Workflow comments

Each approval workflow detail page includes a Comments button where your users can have conversations about the workflow. Comments support threaded replies and user mentions with email and in-app notifications. Commenting on approval workflows requires the Manage approval workflows permission. For more details, see Messages and notifications.

Need help?

If you have any questions about configuring approval workflows, please contact us or email us at support@ftetree.com.