Approval settings and workflows
Overview
Approval workflows define how proposed position changes are reviewed before they become approved position data. Workflows can send requests for review based on department, request type, approval level, FTE impact, and cost impact.
Each submitted request keeps its approval path, approver list, approval level, impact details, attachments, notes, and decisions. If a workflow is changed later, existing requests continue to use the approval path saved when the request was submitted.
Access needed
| Activity | Access needed |
|---|---|
| Configure approval workflows | Manage approval workflows |
| Assign department workflow rules | Manage departments |
| Submit position requests | Create position requests |
| View or respond to requests | View position requests to review; assigned approvers can respond to their approval tasks |
| Reassign an approval task or approve on behalf | Approval management access for the request department |
| Access setup | See Permissions and roles. |
General approval settings
Reminder email settings
- Reminder email days: Sets the number of days between reminder emails sent to approvers.
- Reminder email total: Limits the total number of reminder emails sent to a user for a request.
- Reminder email days back-off: Increases the delay between each consecutive reminder email.
- Reminder email business days only: Counts only business days between reminder emails.
Approval action notes
Notes and reason choices for approving, denying, cancelling, and approve-on-behalf actions are configured under Settings > Audit events > Approval audit events. They are not configured on each workflow.
New organizations include default reason choices for common approval actions. Use reason choices when your organization wants consistent decision categories, and use notes when approvers need to add a short explanation.
Request numbering
- Prefix for request label: Adds a prefix when a request number is displayed.
- Number of digits to pad for request numbers: Pads the sequential request number to a specified number of digits.
Workflow types
Approval workflows are assigned by request type:
- Position change: Changes to an existing position, such as FTE, department, job code, reporting relationship, funding, base wage rate, adjustments, or custom details.
- New position: Creation of a new position.
- Compensation change: A position change focused on wage rate, adjustment, pay range, or related compensation values.
- Replacement or backfill: A request to replace or backfill an approved position without changing the position's core FTE, job code, or cost structure.
- Freeze or unfreeze: A request to pause or resume use of a position.
- Close or eliminate: A request to close a position or remove it from active position control.
Your organization can decide which request types are needed and assign workflows for the departments that use them.
Approval levels
Approval levels provide tiers of review. Higher levels represent more significant changes and can require a more senior workflow.
Each approval level has a display order and name. For example:
| Display order | Level name |
|---|---|
| 1 | Standard |
| 2 | Elevated |
| 3 | Executive |
Position details and custom details can be set to No approval required or assigned to an approval level. Details that require approval create proposed changes that must be submitted in a request. Details that do not require approval can take effect without a request when the user has permission to update the detail directly.
Workflow selection
When a user submits a position request, FTE Tree reviews:
- The request type.
- The department used for approval review.
- The highest approval level required by changed details.
- The FTE impact level.
- The cost impact level.
The selected workflow must meet or exceed the required approval level. If a department does not have a direct workflow assignment, FTE Tree can use an inherited workflow from a parent department.
For existing-position requests, FTE Tree normally uses the position's current approved department to choose the approval path. For new-position requests, it uses the department on the first requested effective date. If no review department can be determined, the request cannot be submitted.
FTE impact levels
FTE impact levels require a higher approval level when a request changes FTE by a meaningful amount. FTE changes can be grouped as:
- Net-zero FTE change: The requested values changed, but FTE did not.
- FTE increase: The requested change increases FTE.
- FTE decrease: The requested change decreases FTE.
Thresholds can escalate larger changes to higher approval levels. For example:
| Impact type | Minimum FTE change | Approval level |
|---|---|---|
| Net zero | 0.0000 | Standard |
| FTE increase | 0.2500 | Elevated |
| FTE increase | 1.0000 | Executive |
| FTE decrease | 0.5000 | Elevated |
Cost impact levels
Cost impact levels work like FTE impact levels, but they use the annualized cost change instead of the FTE change. They can send large wage, adjustment, funding, or FTE-driven cost changes to a higher approval level even when the changed detail itself has a lower approval level.
When more than one detail, FTE, or cost rule applies, FTE Tree uses the highest required approval level.
Workflow steps
Each workflow contains ordered steps. A step defines who can approve, how many approvals are required, and how many denials stop the request.
Approvers can be selected by:
- A named user.
- An approver group.
- A department approval role.
When a request is submitted, FTE Tree resolves the approvers and stores that approval information with the request. This makes later audit review independent of future user, role, or workflow changes.
Attachment requirements
Workflows can require named file slots when a request needs supporting documents, such as a budget worksheet, grant approval, or compensation review. Requesters can also attach optional supporting files when the workflow allows it.
Only require attachments when the document is genuinely part of the approval decision. Too many required slots can slow routine changes and make small requests harder to submit.
Unavailable approvers
If an approver is unavailable, approval managers can reassign the pending task to another eligible user or approve on behalf of the assigned approver when your organization's governance permits it. Both actions are recorded with the request and Activity history.
Reassignment keeps the decision with the new approver. Approve-on-behalf keeps the original approver visible while recording who actually made the decision and why.
Request history review
Each request stores the approval path that applied at submission. That record includes the selected workflow, approval level, workflow steps, resolved approvers, impact details, request reason, attachments, decision notes, reassignment or approve-on-behalf actions, and final applied changes.
Use Activity history to review which actions are recorded and how reason choices or notes can be configured.