Project Approval Levels

One of the most powerful features of ScopeStack is the standardization of project approval flows.

Approval levels are defined in Settings > Governance > Project Approval.

An approval level is a named step in the workflow. Each one has a kind — Technical, Sales or Business — and you can have as many of each as you need, in whatever order you want. When a project is submitted, ScopeStack walks the levels from top to bottom and includes a level only if it applies to that project. Levels that do not apply are skipped automatically.

On this screen: The Project Approval page under Settings > Governance. A card titled Approval Levels holds Active and Archived tabs, each showing a count. The table has six columns: Name, Kind, # Approvals, Trigger, Submitter Approves? and Team Approval?. Rows can be dragged to change the order the levels run in. Selecting one or more rows reveals Archive on the Active tab, and Restore and Permanently delete on the Archived tab. An + Add Approval Level button sits in the card header. When the account has more than one active Technical level, a Consolidate Technical Levels button appears beside it.

The order of the rows is the order of the workflow. Drag a level up or down to change when it runs, so a Sales level can sit before a Technical one if that is how your business works.

Creating an approval level

Click + Add Approval Level.

On this screen: The approval level form. A section headed Identifier & Settings holds a required * Name field with the placeholder “Enter a name”, a required * Kind dropdown offering Technical, Sales and Business (a new level defaults to Business), and a required * Approvals Required number field with the placeholder “Enter a number”. Under those sit two Yes/No toggles: May Submitter Also Approve? and Limit Approval to Submitter’s Team?. Below the toggles are two sections, Triggers and Approvers.

• Name — how the level appears in this list. The project’s own Approvals page labels each step by kind, such as “Technical Approval”, rather than by the level name.
• Kind — Technical, Sales or Business. The kind changes which options appear further down the form, and it is what the project’s status shows while the level is pending.
• Approvals Required — how many approvals this level needs before the project moves on.
• May Submitter Also Approve? — when No, the project’s pre-sales engineer is removed from this level’s approver list for their own projects.
• Limit Approval to Submitter’s Team? — when Yes, only approvers on the same team as the pre-sales engineer count for this level. If the pre-sales engineer is on no team, the restriction does not apply and every approver stays eligible.

A level with a single approver can stall a project. These two toggles are applied after the level has already been selected for the project, so they can leave a level with no one able to approve. The project then sits at that level: the step exists, it has no approvers, and nothing can complete it. The clearest way in is a level whose only approver is also the project’s pre-sales engineer, with May Submitter Also Approve? set to No. Give any level that matters more than one approver. If a project is already stuck this way, add an approver to the step from the project’s Approvals page, or cancel the approval request and resubmit.

Triggers: deciding when a level applies

Triggers are the conditions that decide whether a level applies to a project.

On this screen: The Triggers section of the approval level form. With no triggers defined it reads “Add a trigger to define when this approval level applies.” Once a trigger is added, the rows carry four columns — Measure, Evaluation, Value and Upper (Between) — with a remove control at the end of each row. An Add a Trigger + link sits below the section and is always present.

Measure is the project attribute being tested. The available measures are Contract Cost, Contract Revenue, Contract Margin, Contract Profit, Customized Services, Customized Terms, Net MRR, PS Margin, MS Margin, Payment Credit Amount, Third Party Margin, Third Party Revenue, Total Effort and Business Unit.

On a project whose currency is not the account’s default currency, the money measures are converted into the default currency before they are compared with the trigger value. Those are Contract Cost, Contract Revenue, Contract Profit, Net MRR, Payment Credit Amount and Third Party Revenue. Every other measure is compared as it is: the margins are percentages, and Customized Services, Customized Terms, Total Effort and Business Unit are not amounts of money, so no conversion applies.

Evaluation is the comparison: Greater Than, Less Than, Equal To or Between. Greater Than and Less Than are inclusive. Upper (Between) is only used when the evaluation is Between. When the measure is Business Unit, the value becomes a dropdown of your business units rather than a number.

A level with no triggers applies to every project. A level with several triggers applies only when all of them are true.

Single and multi-condition triggers

When you add more than one trigger to a level, all of them must be true for the level to activate. This lets you build precise rules that combine project attributes.

For example:

• Require CEO approval for any project with revenue above $1,000,000.
• Require approval for all projects in the New Zealand business unit by the leader of that business unit.
• Require managed services leader approval when a project includes managed services revenue greater than $0 and is in the Atlanta business unit.
• Require manager approval when revenue exceeds $10,000 and the project includes one or more custom services.

Requiring approval only when services are customized

A common goal is to require approval only when a project deviates from your standard catalog, and to let fully standard projects through without review. The Customized Services measure does this. It counts the services on the project that are either custom (added ad hoc, not from your catalog) or edited away from the standard.

Set the evaluation to Greater Than and the value to 1 to trigger the level when a project has at least one customized service. Greater Than is inclusive here, so a value of 0 would match every project — use 1 to mean “one or more.” Projects with no custom or edited services then skip this level automatically.

Approvers: deciding who signs off

On this screen: The Approvers section of the approval level form. With nobody assigned it reads “No approvers assigned yet.” Each approver row has an Approver picker with the placeholder “Select an approver”, a Required? checkbox, and a control to remove the row. On a Technical level an extra Lines of Business column appears, defaulting to “Any Line of Business”. An Add an Approver + link adds a row. On a Sales level, the section is introduced with “In addition to the Sales Executive, who should be able to approve the project?”

• Approver — the user who may approve. Each user can appear once per level.
• Required? — a required approver must approve before the level completes. Optional approvers can approve, but the level does not wait on them.
• Lines of Business (Technical levels only) — restricts an approver to projects containing services from the lines of business you choose. Left as Any Line of Business, the approver applies to every project that reaches the level.

On a Sales level, the project’s Sales Executive is always able to approve; anyone you add here approves in addition to them.

Consolidating Technical levels

Accounts that previously configured technical approval per line of business end up with one Technical level for each. If your approvers are the same across them, Consolidate Technical Levels merges them into a single Technical level with the lines of business carried onto the individual approvers instead. The button appears on the Approval Levels page whenever there is more than one active Technical level.

Archiving a level

Levels are archived rather than deleted. Select one or more rows on the Active tab and choose Archive; they move to the Archived tab, where they can be restored or permanently deleted. Archiving a level removes it from future workflows and leaves the approval history on past projects intact.

Requesting Approval

After you have created a project with services, you can submit it for approval. The Request Approval button is in the project header, the strip across the top of every project page, so it is there whichever tab you are on, including Overview.

On this screen: The project header at the top of a project page, above the navigation tabs. On the right, beside the Generate Document button, sits a Request Approval button. It appears while the project is in the Building state and the current user has the Request Approval permission set to Manage. If your account has renamed this button, the header shows your label instead. Clicking it submits the project into the configured approval workflow.

Who can request approval is controlled by role-based permissions. Users must have the Request Approval permission enabled on their role to submit a project through the approval process. See Roles and Permissions for details on configuring this permission.

After you submit your project for approval, the platform automatically sends email notifications to the appropriate approval users as configured in Settings, triggered based on the details of the project. The email contains basic project information so the approver can quickly review.

On this screen: The approval notification email sent to designated approvers. The subject line follows the format “[Client Name] / [Project Name]: Approval Required” (or “Optional” depending on the approver’s designation). The email body includes the project’s client name, project name, and a link to review the project in ScopeStack. Standard attachments include a project summary document and a work breakdown document.

The icon next to the project in the list will also change from yellow to red while it is pending approval.

What emails the workflow sends, and who gets them

Each stage sends a different email to a different person. Knowing which is which saves a lot of “why didn’t I get notified” guesswork.

Three consequences worth knowing:

• Approvers are not told when a project finishes. The final confirmation goes only to the Pre-Sales Engineer and the Sales Executive. If someone who approved at an earlier level wants to know the outcome, there is no setting for it. The project_status_changed webhook is the way to build that yourself.
• Approvers are not told when another approver acts. On a level needing two approvals, the second approver is not prompted when the first one approves.
• A recipient with no email address is skipped silently. Nothing warns the sender, and nothing appears in a log a customer can read. This bites most often on a Sales Executive record created without an email, where the approved notification simply never goes out.

Reviewing what is waiting on you

Approvers have a dedicated list of the projects awaiting their decision, reached from Approvals in the main navigation. It shows Project Name, Customer, Revenue and Margin.

The list only includes projects that are still in an approval stage. A project that has been approved, or whose approval request was canceled, drops off the list rather than lingering on it.

Clicking a project name opens that project’s Approvals section directly, so you land on the approval detail rather than the general project edit page.

Canceling Approval Requests

Any user with a Role that has the Project Overview permission set to Manage can cancel the approval request of any project. This brings the project back to the Building state, making it editable, and you can submit it again once you are done.

Cancelling an approval request does not cancel the project. The pending approval step is marked cancelled and the project returns to Building with its services, pricing and documents intact.

On this screen: The project header at the top of a project page, for a project currently in the approval flow. In the place where Request Approval appeared, a red Cancel Approval button is shown. Clicking it cancels the approval request, shows “The Project approval has been canceled!” and reloads the page with the project back in the Building state where it can be edited.

The Cancel Approval button is in the project header on every project page, not only Overview, while the project is waiting on any approval level.

How Approval Changes Take Effect

ScopeStack records each step’s approver list when that step is created. Editing your approval rules does not rewrite that list, but completion checks can use current approval settings. In the unified workflow, later levels are selected from your current rules as the project advances.

To replace the approver list already stored on a pending step, cancel the approval request and request approval again. The request rebuilds from your current rules. Not every change needs this: in the unified workflow, a change to Approvals Required applies to a pending step the next time someone approves it, and later levels use your current rules as the project advances. Note that re-requesting restarts the workflow from the beginning, so approvals that were already given will need to be given again.

Completing the Approval Flow

An Approvals section will also appear in the project’s menu, giving you a rundown of who needs to approve a project before it can proceed. It stays updated as approvals are completed.

On this screen: The Approvals section within a project, accessible from the project’s left navigation menu. The page shows a card titled “Approvals.” Inside, each project version is displayed as a collapsible section with the version name (e.g., “Version 1”) and a “See Version Changes” link. Expanding a version reveals a summary table with three columns: Status (Pending, Approved, or Declined, with Approved shown in green and Declined in bold red), Approval Step (the step name such as “Technical Approval” or “Business Approval”), and Approvers (the count of approvers for that step, with a gear icon visible on pending steps to add additional approvers). Each step row is expandable to show the detail table of individual approvers.

An approver can click on their status and select whether to approve or decline the project, and leave comments for the project creator.

On this screen: The approval detail table expanded for one step. It shows individual approver rows with five columns: Status (the individual’s decision: Required, Optional, Approved, or Declined), User (the approver’s name), Reason (populated when declining), Comment (free-text notes from the approver), and Date (when the approval action was taken, blank for pending approvers). For approvers who can act on the project, a “Review →” link appears in the Comment column that opens the review modal.

After a project is approved at one level, it moves on to the next level of approval as applicable.

On this screen: The Approvals page showing a project that has passed Technical Approval and is now pending at a second approval step. The Technical Approval step row shows Status “Approved” in green. The next step row shows Status “Pending” with its approver count. The expanded detail table for the pending step shows approvers with “Required” or “Optional” status and no completion date yet.

If a project is not approved it returns to Building, whatever the level and whatever the reason.

On this screen: The review modal opened by clicking “Review →” on an approval row. For Technical and Sales approval steps, the modal shows a Comments text area and two action buttons: Approve (with a thumbs-up icon, styled in blue) and Decline (with a thumbs-down icon, styled in secondary/gray). For Business Approval steps, the Decline button is replaced by Adjust Scope and Adjust Price, plus a red Cancel button behind a confirmation prompt.

Whichever of those an approver chooses, the project returns to Building and stays editable. Decline, Adjust Scope, Adjust Price and Cancel all land in the same place; what differs is the notification the team receives and the reason recorded against the approval. Resubmitting starts the workflow again from the first level that applies.

⚠️ This changed with the unified workflow. Before it, an approver choosing Cancel moved the project to a Canceled status that could not be reopened from the interface, and Adjust Price stepped back to the Sales level where one was required, rather than to Building. If you are looking at a project cancelled earlier in 2026, that is why it is stuck.

Resubmitting starts the workflow again from the first level that applies, in the order the levels appear in Settings. The same skip logic applies on resubmission: if a level’s triggers do not match the project, the workflow advances past it automatically. Email notifications are sent throughout the process to notify users when action is needed. Every time a project is submitted for approval, the platform creates a new version.

On this screen: The Approvals page for a project that has been through multiple approval cycles. Multiple version sections appear (e.g., “Version 1,” “Version 2”), each collapsible. Earlier versions show their final approval status. The most recent version shows the current state of the approval flow with its step statuses. Each version section includes a “See Version Changes” link that navigates to the audit log for that version.

Tracking submission and approval dates

The Approvals page shows who approved each step and the date they acted, but not when the project was originally submitted. To see both the submission and final-approval dates, add the Submitted On and Approved On columns to your Project List from the Customize Columns panel. Both columns are sortable, so you can order projects by either date.

To measure approval cycle time across projects (for example, for internal SLAs), turn on both columns and export the project list to CSV. The export includes whichever columns you have enabled. The columns on screen show the date only, but the exported CSV includes the time of day as well, so use the export when you need precision finer than a day.

Note that Submitted On reflects the most recent submission. If a project was sent back for changes and resubmitted, the date shows the latest submission rather than the first.

Troubleshooting

Technical Approval is being skipped

If a project advances past Technical Approval without stopping for peer review, check the following:

1. Is there a Technical level that applies? Go to Settings > Governance > Project Approval. A Technical level applies only if at least one of its approvers covers a line of business used by the project. An approver set to “Any Line of Business” covers every project; one restricted to specific lines of business only counts when the project contains services from them. If no approver matches, the level is skipped.
2. Do the level’s approvers cover the project’s lines of business? An approver restricted to specific lines of business only counts on projects that use them. If none of the level’s approvers matches, the level is skipped.

A project is sitting at an approval step with nobody able to approve

This is the other outcome, and it looks like the workflow has hung rather than skipped a step. The level was selected, then May Submitter Also Approve? or Limit Approval to Submitter’s Team? removed everyone from it.

1. Open the level and check whether its only approver is the project’s pre-sales engineer while May Submitter Also Approve? is No.
2. Check whether Limit Approval to Submitter’s Team? is Yes and no approver shares a team with the pre-sales engineer.
3. To clear the project now, add an approver to the pending step from its Approvals page, or cancel the approval request and resubmit. To stop it recurring, add a second approver to the level.

Sales Approval is not appearing

A Sales level applies when the project has a Sales Executive assigned, or when the level lists approvers of its own. A Sales level with no extra approvers on a project with no Sales Executive is skipped.

Project went straight to Approved

If a project moves directly from Building to Approved when submitted, check that the Approval Workflow feature is enabled under Settings > Account > Account Preferences. When this feature toggle is off, submitting a project for approval immediately sets its status to Approved.

Someone approved, but the step still shows Pending

An approval step completes only when two conditions are met: every approver whose status is Required has approved, and the total number of approvals meets the level’s required approval count. A step can therefore stay Pending after a valid approval if another required approver hasn’t acted yet, or if the level requires more approvals than have been given (for example, a level set to 2 approvals with only one signature so far). Expand the step’s detail table on the project’s Approvals page to see exactly which approvals are outstanding. Also confirm the level doesn’t require more approvals than it has eligible approvers — such a step can never complete.

An approver I removed keeps appearing on projects

Two common causes:

1. The user is an approver on more than one level. Check the full list under Settings > Governance > Project Approval. Pay special attention to levels with broad triggers, or with no triggers at all, since those apply to every project and bring their approvers with them.
2. The project’s approval step predates your change. Each approval step keeps the approver list from when that step was created. See “How Approval Changes Take Effect” above. Cancel and re-request approval on the affected project to pick up the new configuration.

My project stops for Technical Approval more than once

If your account has a separate Technical level for each line of business, a project spanning several of them pauses once per matching level. To collapse those into a single technical review, open Settings > Governance > Project Approval and click Consolidate Technical Levels. It merges the active Technical levels into one and carries the lines of business onto the individual approvers, so each person still only reviews the work they are responsible for. The button appears whenever there is more than one active Technical level.

Approving a step fails on a project that was submitted before the account moved to the unified workflow

Some older steps have no approval level. They no longer cause an error when someone approves them; they use the legacy completion checks. If you still see one stuck, cancel the approval request and resubmit.

A later approval level looks like it was bypassed

Approval levels run in sequence and the workflow only ever moves forward, so a project sitting in an earlier level has not skipped a later one. The later level has not been evaluated yet.

Levels run in the order they appear in Settings > Governance > Project Approval, top to bottom, whatever their kind. Drag a row to change it. A level is skipped when its triggers do not match the project, or when none of its approvers covers a line of business the project uses. A level that passes those checks and then loses its approvers to the submitter or team toggles is not skipped: it becomes a step with no approvers, and the project waits there.

One thing this does not guarantee: reaching a level is not the same as running it. Each level is checked against the project at the moment the workflow advances to it, and a level whose conditions the project does not meet is skipped then. So a level that has not run yet may still be skipped when its turn comes. The Approvals page on the project shows what actually happened at each step.

A project jumped to Won while approvals were still outstanding

This one is specific to Microsoft Dynamics. If your Dynamics connection has Should Mark Won? enabled, an opportunity moving to Won in Dynamics sets every linked ScopeStack project to Won on the next sync, including projects that are mid-approval. The remaining levels do not run.

The outstanding approval requests are left in place rather than cancelled, so if an approver acts on one afterwards the project can move back out of Won. If that happens, cancel the approval on the project to clear it.

This does not apply to Salesforce, HubSpot, ConnectWise or Autotask connections. If you are on one of those and a project reached Won unexpectedly, the cause is something else and support can help trace it.

Approval notification emails not arriving?

If your organization uses a web proxy or SSL inspection tool (such as Cisco Secure Access, Zscaler, or similar), approval notification links may be blocked. ScopeStack sends emails through SendGrid, which uses click-tracking URLs on the url3021.scopestack.io subdomain before redirecting to app.scopestack.io.

Ask your IT team to allowlist *.scopestack.io (wildcard) on your proxy or SSL inspection policy. This covers both the application domain and the email click-tracking subdomain.