Defining Technical, Sales, and Business Approval Users

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

Check out this video overview of the feature:

Watch video on YouTube 

Approvers for projects are defined in Settings > Governance > Project Approval. Admins can set up Project Approval at 3 levels: Technical, Sales, and Business.

When a project is submitted for approval, ScopeStack evaluates each level in order. Each level only appears in the workflow if its conditions are met:

• Technical Approval appears when the project contains services from a Line of Business that has a LOB Approval configured with at least one eligible approver.
• Sales Approval appears when the “Add Sales Executive approval?” toggle is enabled and the project has a Sales Executive assigned.
• Business Approval appears when the project meets at least one configured Business Approval level’s trigger conditions.

If a level’s conditions are not met, the workflow advances past it automatically. For example, if a project uses a Line of Business that does not have a LOB Approval configured, Technical Approval is skipped and the project moves directly to the next applicable level.

Technical Approval allows you to designate specific users or groups of users to approve projects.

On this screen: The Technical Approval settings page under Settings > Governance > Project Approval. Three tabs appear at the top: Technical Approval, Sales Approval, and Business Approval, with Technical Approval active. The main content shows a table listing each configured LOB Approval with columns for Line of Business, # Approvals, Submitter Approves?, Team Approval?, and Project Technical Approval (the list of assigned approvers). A ”+ LOB Approval” button at the bottom allows adding approval configuration for additional Lines of Business.

To define an approval stage for a specific Line of Business, click the ”+ LOB Approval” button.

On this screen: The Add LOB Approval form. It contains four fields: Line of Business (a required dropdown listing Lines of Business not yet configured), Number of Approvals Required (a number field, minimum 1), May Presales Engineer Also Approve Project? (a checkbox with helper text “When checked, presales engineer on a project may also approve it”), and Restrict Technical Approval to Team? (a checkbox with helper text “When checked, technical approval will be restricted to members of the team(s) to which the presales engineer is assigned”). A Submit button and Back link appear at the bottom.

Here, you can define the approval parameters for a specific Line of Business.

1. First, select the Line of Business to create an approval mechanism for
2. Next, select the number of approvals necessary for technical approval to be achieved. Be aware that if you require more approvals than the number of users in your designated pool who can authorize the project, you risk creating a situation where the project cannot be approved.
3. Determine whether the presales engineer assigned to the project should have approval authority. This decision can affect the number of available approvers needed to satisfy the required approvals.
4. If you are using Teams, decide if you want the approval to be limited to the same team as the Presales Engineer on the project. If you restrict approval to a team, please ensure there are enough approvers from each team in the pool to satisfy the number of approvals required to approve the project.

After you’ve defined these settings, click Submit. Now, you can define users who may approve of the project. To add a potential approver for this Technical Approval level, click ”+ Add Approval User.”

On this screen: The lower portion of the LOB Approval edit page, below a horizontal rule after the main settings form. A section titled “Users Who May Approve Projects with [Line of Business Name] Services” shows a table with four columns: Approver (user name or email), Teams (the teams the user belongs to), Required? (whether this user is a required approver), and an action column with a delete button. A footer row below the table contains a + Add Approval User button.

Here, you can define users who can approve of a project. You can also designate specific users as required approvers.

On this screen: The Approval User table with multiple approvers configured. Each row shows the approver’s name, their team membership, and a “Required?” column showing either “True” or “False.” Users marked as required show “Required” in that column; others show “Optional.” The delete button in the action column allows removing an approver from the pool.

Users designated as Required Approvers must approve a project for it to advance through the approval process. This system is beneficial for establishing groups where certain users are mandatory for approval, while others are optional. It is important to note that even if the overall number of approvals has been met, a project will still need the approval of any Required Approver who has not yet given their consent.

On this screen: The LOB Approvals list page showing all configured Lines of Business with their approval settings. Each row displays the LOB name, the number of approvals required, and the list of approval users assigned to that LOB. Clicking a row opens that LOB’s approval configuration.

Using these settings, you can create several different permutations of Technical Approval situations.

LOB-Level Approvals

Approval steps are configured per Line of Business. When LOB-level approvals are enabled, each LOB on the project is evaluated independently against its own approval rules. A project with services from two different Lines of Business must satisfy the approval requirements for each LOB separately before advancing.

Only Lines of Business that have a LOB Approval configured will trigger the Technical Approval step. If your account has Lines of Business without a LOB Approval record, projects that use only those LOBs will skip Technical Approval entirely. To ensure all projects go through peer review, add a LOB Approval for every active Line of Business.

“May PSE Also Approve” setting

By default, the Pre-Sales Engineer assigned to a project cannot also serve as an approver on that same project, enforcing separation of duties. The “May Presales Engineer Also Approve Project?” checkbox on the LOB Approval configuration overrides this restriction, allowing the PSE to approve their own projects.

If a PSE is configured as an approver but does not appear in the approver list on a project they authored, check this setting at Settings > Governance > Project Approval on the relevant LOB’s approval configuration.

Sales Approval provides an opportunity for the Sales Executive designated on a given project to review the project.

On this screen: The Sales Approval tab under Settings > Governance > Project Approval. The page shows a single toggle control labeled Add Sales Executive approval?. When enabled, the Sales Executive assigned to a project must review it before it can proceed to Business Approval. The setting is saved automatically when the toggle is changed.

Business Approval provides a final step of approval for projects.

It is activated based on specific logical conditions and can request particular users to approve or deny based on the criteria met by a project.

On this screen: The Business Approval tab under Settings > Governance > Project Approval. A table lists existing Business Approval levels with columns for Name, # Approvals, Trigger, Submitter Approves?, and Team Approval?. Levels are reordered by dragging, and one or more levels can be removed by selecting them and deleting. A + Add Business Approval button adds a new level.

To create a new Business Approval level, click the + Add Business Approval button.

On this screen: A Business Approval level editor panel. It contains fields for the number of approvals required, a toggle for whether the presales engineer may approve their own projects, and an option to restrict approvals to the same team as the presales engineer. Below those settings is an “Add Project Test” button for configuring trigger conditions. Each condition row lets you choose a project attribute (such as revenue or business unit) and set a threshold or value. A Submit button saves the configuration.

The same settings for Number of Approvals Required, whether the Presales Engineer may approve their own projects, and restricting approvals to a team from the Technical Approval setup all apply in the Business Approval setup.

Instead of requiring approval based on the presence of services, Business Approval lets you define trigger conditions based on specific project parameters. If the project meets those conditions when approval is requested, that approval level is triggered.

Single and Multi-Condition Triggers

Each Business Approval level supports multiple trigger conditions. When you add more than one condition, all conditions must be true for the approval level to activate. This lets you create 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.

To configure conditions, navigate to Settings > Governance > Project Approval and click the Business Approval tab. Edit an approval level and click Add Project Test to define each trigger. You can combine as many conditions as needed.

After defining your conditions, click Submit to save. To remove a condition, select its checkbox and click Submit again.

Once you’ve defined your conditions, set up your pool of approval users the same way you set up approvers at the Technical Approval level.

Requiring Approval Only When Services Are Customized

A common goal is to require business approval only when a project deviates from your standard catalog, and to let fully standard projects through without review. The Customized Services trigger measure does this. Edit a Business Approval level, click Add Project Test, and choose Customized Services as the measure. 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 operator to Greater Than and the value to 1 to trigger the approval 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.

Requesting Approval

After you have created a project with services, you can submit it for approval. Under Project Overview, you will see an option to Request Approval.

On this screen: The project Overview tab showing a “Request Approval” button. The button is visible when the project is in the Building state and the current user has the Request Approval permission. 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.

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.

On this screen: The project Overview tab for a project currently in the approval flow. A Cancel Approval button (styled in red/danger) with a ban icon appears in the action button area. Clicking it cancels the approval request and returns the project to the Building state where it can be edited.

The Cancel Approval Request button is visible on the Project Overview screen for any project in the approval flow, provided you have the appropriate permission.

How Approval Changes Take Effect

When a project is submitted for approval, ScopeStack records the approver list for each step at that moment, based on your approval rules as they exist at submission time. Editing your approval rules afterward — adding or removing approvers, changing the number of required approvals, or adding and deleting approval levels — does not change approval requests that are already in flight. Those requests keep the approver list they were created with.

To apply rule changes to a project already in the approval process, cancel the approval request and request approval again. The request rebuilds from your current rules. 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 will move back through the process depending on where it was declined and why.

• At the business level, a project can be declined on either Scope or Price. If declined on Scope, it moves back to the Presales Engineer. If declined on Price, it moves back to the Sales approval if applicable.
• If declined at the Sales level, or if the Sales level is not required, the project moves back to the Presales Engineer to adjust before resubmitting.

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 two options: Adjust Scope (returns the project to the presales engineer) and Adjust Price (returns to the Sales approval step if applicable), plus a red Cancel button that permanently cancels the project after a confirmation prompt.

Once a project is resubmitted, it moves back through the Technical Approval process before proceeding to Sales and Business as applicable. The same skip logic applies on resubmission: if a level’s conditions are not met, 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. Does the project’s Line of Business have a LOB Approval configured? Go to Settings > Governance > Project Approval > Technical Approval. If the LOB used by the project is not listed in the table, add it with ”+ LOB Approval” and assign at least one approver.
2. Are there eligible approvers after filtering? If “Restrict Technical Approval to Team” is enabled but the Presales Engineer is not assigned to a team, no approvers will be eligible and the step will be skipped even though a LOB Approval exists. Ensure the Presales Engineer has a team assignment, or disable the team restriction.
3. Is “May Presales Engineer Also Approve” disabled? If the only configured approver for a LOB is also the Presales Engineer on the project, and this setting is unchecked, there will be no eligible approvers. Add additional approvers to the LOB Approval pool.

Sales Approval is not appearing

Sales Approval requires two things: the “Add Sales Executive approval?” toggle must be enabled on the Sales Approval tab, and the project must have a Sales Executive assigned. If either condition is not met, the step 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 Account Settings > Advanced. 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 attached to more than one approval rule. Check all three tabs under Settings > Governance > Project Approval. Pay special attention to rules with broad trigger conditions (such as Contract Cost greater than $0), which include their approvers on every project.
2. The project’s approval request predates your change. Approval requests keep the approver list from when they were 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

Each Line of Business with a LOB Approval configured generates its own technical review step. A project containing services from multiple Lines of Business will pause for technical approval once per matching LOB, each with that LOB’s approver pool. If you would prefer a single combined technical review step for multi-LOB projects, contact support and we can consolidate them for your account.

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.