Approval workflows and requests

Overview

Approval stages define the reviews a position request must complete before its changes take effect. Your organization has one separate approval workflow for each request type: New position, Position replacement, Position change, and Position elimination. Each workflow has its own ordered stages, normal approval path, and department approvers.

A request that requires a later stage also completes every earlier stage in that request type’s workflow. For example, a New position request requiring Executive Committee review completes its Department Sponsor and Finance Review stages first. A Position replacement request can follow a shorter, independent path such as Hiring Manager and People Operations.

New organizations receive a separate Stage 1 - Department Manager in each of the four workflows. Each workflow initially completes through that stage. You can rename the stages, add stages, assign different approvers, and change each normal approval path independently.

Each submitted request keeps its selected Reason text, whether Justification was required, stages, approvers, and comment requirements. Later setup changes apply only to future requests.

1. Department ManagerThe request starts with the first required review.
2. Finance ReviewThe next stage opens after the earlier stage approves.
3. Executive CommitteeThe final required approval applies the request.

Access needed

Configure each request-type workflow

Open Approval workflows in organization settings. The list has one row for each request type. Choose a workflow, then use its Stages tab to create stages in the order requests of that type should follow. Use Workflow defaults to choose the final stage every request of that type must complete, select its Reason group, and decide whether sensitive Justification is required.

Keep each list short. Add a stage only when it represents a distinct decision that must be recorded. Use the move controls to change the order within that request type.

The four workflows are independent. A stage called Finance Review in New position is different from a stage with the same name in Position elimination. Its order and department approvers can differ. A department can have different approvers for different request types, but it cannot define its own stage sequence.

Choose Make unavailable when a stage should not be offered for new setup in its request type. A stage already selected under Workflow defaults remains selected and labeled unavailable until you deliberately change it. Existing department approver assignments remain visible but read-only. A Position change stage already selected by a field also remains visible until you change the field. Submitted requests keep the stages and approvers selected when they were submitted. Choose Make available if the same stage should be used again. Earlier requests and their history are not deleted.

Assign approvers by department

Open a workflow’s Stages tab and review the department approvers for each stage. For each department, select one or more organization members who may decide that stage for its requests. Assign at least two when practical so an absence does not block the stage; FTE Tree warns when only one current approver is configured. An approver does not need to belong to that department and may be selected from anywhere in the organization.

When an organization member has a Job title, FTE Tree shows it with the person’s name in approver selectors and approval progress. The title is identification only; stage assignment and access roles determine who may act.

The stage name describes the review; it does not select a manager automatically. For example, naming a stage Department Manager does not use position or employee reporting relationships. Select the organization members who should approve at each department.

For each selected stage, FTE Tree starts with the approvers assigned directly to the request’s department. If that department has none for the stage, FTE Tree uses the nearest higher-level department with assigned approvers for the same stage. A direct assignment replaces the inherited assignment; the groups are not combined.

At each active stage, any one assigned approver for the request’s department can decide the stage. When one person acts, the other assigned approvers no longer need to act. There is no setting to require every assigned approver or unanimous agreement. The requester cannot approve their own request. If no other active approver is available, submission is blocked until the assignment is corrected.

Department assignment example

This example shows two stages in the New position workflow across one branch of a department tree:

A West Plant New position request therefore goes first to Jordan and Casey, then to Priya and Lee when Finance Review is required. It does not add Alex and Morgan to the Department Manager stage. Any one eligible person in each stage can complete that stage. A Position replacement request uses its own stages and approvers instead.

Configure workflow defaults

Open a workflow and choose Workflow defaults. Complete through selects the final stage every request of that type must reach. The approval path always starts at Stage 1 and includes every stage through that selection.

New position, Position replacement, and Position elimination use only their own default route to determine how far the request goes. Position field approval settings do not change those routes. Stages after the selected route are not used until you extend the default route.

Position change can also use Field approval stages. A field can select a stage only from the Position change workflow. Stages after the Position change default route are available for field-specific review. FTE Tree completes through the later of the default route and the stages assigned to the changed fields. A field’s data type, such as Text, Currency, or Select, does not choose the route.

A Position field set to No field approval requirement does not extend the Position change route. It does not remove stages included by default. Choosing No default stage - use Position change field rules lets changed fields determine the route. The other three workflows offer No default stage - no approval by default because they do not use field stages. A request with no required stage is approved automatically after submission and file checks pass.

For a new position, all initial values remain proposed until the complete request is approved. An intermediate stage never applies only part of the position.

For example, the Position change default route can complete through Department Manager, Position name can have no additional field requirement, and Pay rate can require the later Finance Review stage. A name-only Position change stops after Department Manager, while a pay request continues through Finance Review. New position still follows only its own default route and approves all initial values together.

Configure Reason and Justification

Every request requires one Reason from the Reason group selected for its request type. New organizations start with a separate group of meaningful choices for Position change, Position replacement, New position, and Position elimination. Open Manage choices in this Reason group to rename, add, reorder, make unavailable, or restore choices. Keep the choices short, distinct, and safe for every person who can open the request.

Justification is a separate free-text field. It is optional by default. Turn on Require sensitive justification for a request type when reviewers consistently need additional narrative that the Reason choice cannot capture. This setting applies only to future submissions; a submitted request keeps the requirement and Reason text captured when it was sent.

Reason is ordinary request information and is visible to anyone currently allowed to open the request. Justification is always sensitive, whether it is optional or required. The organization can require Justification, but it cannot make Justification non-sensitive or broaden its audience.

Request types

Open a request type under Approval workflows to build its stage list on Stages, then choose Workflow defaults to set its normal route and intake. The starter default route ensures every type receives human review until an administrator deliberately changes it.

Here is one possible setup:

Add files to requests

Requester-file fields are configured separately, then added to the workflows that need them. See Set up requester files for file audiences, templates, stage conditions, required choices, and launch checks.

Protected request information and reminders

Every request requires one configured Reason. Justification is optional unless the request type’s Workflow defaults require it. In addition to any named fields, requesters may add optional files in one additional supporting-files area. These additional files always require complete current Position access and View sensitive workforce data. A named file uses the audience selected in the requester-file library. Organization file-count and size limits apply to named and additional files together, and a file cannot be downloaded until its safety check finishes successfully.

The selected Reason is visible with the request shell. Justification, decision and override explanations, comments, exact costs, and files labeled Sensitive access required may contain sensitive information. Viewing them requires current Position access and View sensitive workforce data for every part of the request. An assigned approver or approval administrator may still have authority to record a decision while protected information shows as Restricted.

Approval settings also control the request-number label and reminder email timing. Only the active stage’s eligible approvers receive the initial message and reminders.

Configure decision comments

Approval settings provide separate choices for Require comments when approving and Require comments when denying. Approval comments are optional by default, and denial comments are required by default. An organization can turn either requirement on or off.

The selected outcome determines which rule applies. The same rule applies when the assigned approver responds directly and when an approval administrator responds on that approver’s behalf. A submitted request keeps the rules that applied when it was sent, so a later settings change affects only future requests. The Override request action always requires a reason.

Administrative approvals

The Administrative approvals area is available to users with Administer active approval requests. A person also needs current Position access to the request department and cannot administer a request they submitted. This permission does not add Position access or View sensitive workforce data.

It is separate from Manage organization settings. Approval administrators can recover active requests, but they cannot change request-type workflows, stages, workflow defaults, Reason groups, Justification requirements, Department approver assignments, requester file requirements, blank templates, or reminders. Settings administrators cannot use administrative request actions unless they also receive Administer active approval requests and the required Position access.

Administrative approvals has three views:

• Needs attention shows at most one row per affected request when none of its assigned approvers has an active account, when the stage has waited through the first configured reminder interval, or when a file check failed or remained pending too long. It does not reveal a protected filename.
• Available shows current assignments held by another approver for which the administrator can record a response.
• Completed shows only responses recorded for another approver that are still covered by the administrator’s current position access.

Needs attention does not reassign the request, change its submitted approver list, move the request to another stage, or create a new deadline. A stage problem offers Respond for actions for the saved approvers. A file-only problem offers Open because a file condition is not an approver decision.

Decisions recorded for another approver and overrides

An approval administrator can record Approve or Deny request for an approver assigned to the current stage. The original approver remains visible, the administrator is recorded as the person who acted, and the organization’s normal comment rule for the selected outcome applies. There is no separate required explanation for acting on another approver’s behalf. An original approver whose membership and account are still active receives a message in FTE Tree.

An approval administrator can also override the entire request with Approve request or Deny request. An override records the administrator’s own exceptional decision, closes all remaining stages, and always requires a reason. Requesters cannot record a decision for another approver or override their own requests.

Direct approval, approval recorded for another approver, and an approve override all wait until every submitted file passes its safety check. Direct denial, denial recorded for another approver, and a deny override remain available when the request should close. Current access, requester exclusion, and request status are checked again when the response is submitted.

Review setup before launch

Test at least one request for each important department and request type. Confirm that:

• Each request follows only its request type’s stages, default route, and Department approvers.
• Each request type offers the intended Reason choices, rejects a missing or cross-type choice, and shows the submitted Reason to every current request viewer.
• Optional Justification can be left blank, required Justification blocks a blank submission, and Justification remains restricted without complete current sensitive access in both cases.
• Renaming a Reason or changing the Justification requirement affects only later submissions.
• Position change can extend beyond its default route for changed-field stages, while the other three types use only their default route.
• Requester-file setup has passed the separate checks in Set up requester files.
• Each required request-type stage uses approvers from the expected department.
• The requester is not the only eligible approver.
• Important stages have at least two effective approvers where practical.
• Approvers can see the request information they need without receiving unrelated access.
• Approval and denial produce the intended outcomes and enforce their configured comment rules for direct decisions and decisions recorded for another approver.
• Needs attention, Available, and Completed contain only the intended requests and reveal no protected information.
• A decision recorded for another approver names both people, while an override names the administrator and required reason.
• Approval administration and approval setup remain separate permissions, and neither expands Position or View sensitive workforce data.
• A change to approved position information invalidates an outdated pending request, and later work starts as a complete new request without copied values or approvals.