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 “Require sales review before business 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 ”+ Add 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 ”+ Add 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 Require sales review before business 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 three columns: Name, Approvers (a comma-separated list of users assigned to that level), and an action column with up/down reordering buttons and a delete button. The footer row contains a + Add Approval Level button.

To create a new Business Approval level, click the + Add Approval Level 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.

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.

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.

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 ”+ Add 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 “Require sales review before business 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.

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.