August 2026 Changelog

August was a reliability month. Most of the work went into integrations, the accuracy of the audit log, and making sure the same number means the same thing everywhere it appears. Alongside that, catalog approvals that had been lost in an earlier migration are back, and the Preferences pages now tell you where each feature stands.

Catalog approvals are enforced again

If your account designates Service Approvers for a line of business, that approval step is working again on the current Settings pages.

Editing a catalog service, subservice, rate, or level of effort under Settings > Content > Professional Services or Managed Services now sends that item back to Pending review unless you are one of the configured approvers for its line of business. On the Pending tab, approving an item is now restricted to the approvers configured for that item’s line of business.

Both behaviors existed in the older admin screens and kept working there, but did not carry over when catalog management moved onto the current pages. This mostly restores them rather than adding something new. One part is new: editing a rate or a level of effort now sends the item back for review, which the older screens never did. Until this shipped, an edit made through the current Settings pages did not send the item for review even on accounts that require it; edits through the older admin screens were unaffected.

See what is coming, and where each feature stands

The Account Preferences page (Settings > Account > Account Preferences) and your personal Preferences page (User Profile > Preferences) now show a Coming Soon section listing features in development, each with a name, a description, and an expected beta date where one has been set.

On the same pages, each feature toggle can now carry a small status badge reading Beta Test or Released, and a line reading “Generally available” with a date underneath its description. Toggles with neither value set look exactly as they did before.

Control who can change personal preferences

A new User Preferences permission controls who can see and change the Preferences tab on a user’s profile, where personal feature opt-ins live. Set it per role under Settings > Users & Groups > Roles. On accounts created from now on, the built-in Admin role can manage it and the built-in User and Sales roles cannot. On roles that already existed, and on any new role you create, it starts unset, which denies access — so until an admin sets it to Manage on a role, nobody on that role can open the Preferences tab described above.

Version history on users and document templates

The user edit screen and the document template edit screen now carry a Version History tab. On the document template screen it appears for anyone whose Version History permission is View or Manage; on the user screen it appears for anyone whose Users permission is Manage. It lists what changed, when, in your account’s configured date and time format, and who made the change. Expanding a row shows the detail: which field changed, what it was, and what it became. With Version History set to Manage, a revert control on each row rolls that record back to its state at that point, after a confirmation prompt.

Early access

• In-app notifications. A notification bell in the top navigation shows unread count, opens a preview panel of unread notifications, and links to a full Notifications page where you can page through history, select multiple notifications, and mark them read, mark them unread, or archive them. Account admins get a Notification Policies tab under Settings > Account for setting account-wide defaults per notification type, with separate in-app and email toggles, which individual users can still override on their own profile. This is available to a small number of accounts while we finish it. Contact support if you would like to be included.

For integrators

• Line of business and service category totals in V2 merge data. Each entry in lines_of_business, and each entry in the service_categories nested under it, previously carried only a name, code, slug, and its list of services. Both now also carry total_revenue, total_cost, service_revenue, service_cost, pm_revenue, service_hours, and total_hours, summing every service filed under that node including its subservices. A template can now total a category or a line of business directly instead of aggregating across a nested loop. Note the typing: these totals are emitted as JSON strings rather than numbers, whole values included, so a node totalling 38 hours arrives as "38.0". That is the existing behavior for money and hours throughout the payload, not something new here, but it means an expression that sums across categories will concatenate strings instead of adding numbers. Coerce before you aggregate.
• Audit log date filters work in both directions. On /v1/audit-logs and /v2/audit-logs, filter[before] previously had no effect at all: a request scoped to changes before a given date returned every record. filter[after] failed the opposite way, returning nothing when given a blank or unparseable value instead of ignoring it. Both bounds now filter correctly, and an unusable date on either side is ignored rather than emptying the result. If you sync audit records in date windows, re-check any assumptions built on the old behavior.
• Document and attachment downloads now require an authenticated request. The document-url attribute returned by the project-documents and document-requests resources, on both v1 and v2, now points at a ScopeStack API endpoint rather than a storage link, so it must be fetched with your Bearer token and can no longer be stored or passed to a third party as a standalone URL. Separately, GET /v2/project-attachments/{id}/download is now /downloads. If you fetch documents or attachments over the API, check both before your next sync run.
• Several API errors now return the right response. Sending service_type on a project subservice through POST or PATCH returned a server error; a subservice always inherits its parent service’s type, and the field is now rejected as uneditable rather than crashing. GET /v2/sales-executives?include=account returned a server error and now returns the account. An approval level trigger submitted without its measure or evaluation returned a server error instead of a validation error naming the missing field. Listing project collaborators returned a server error for the whole collection if any one collaborator’s user record had since been deleted, rather than returning the others; the request now succeeds, with an empty name on the affected entry.
• Release status on flag values. GET /v2/account-flag-values and GET /v2/user-flag-values, and their show routes, now return general-availability-date and status on each flag. status is beta_test or released. Both are null for a flag with no release record.

Fixes

• Audit log and version history no longer come up empty. A project whose history included a teammate later removed from the account, or a change to a feature ScopeStack has since rebuilt, would show no history at all rather than skipping the one entry it could not read. Both cases now display, with a blank name or summary on the affected row, and the rest of the history intact.
• Changes made through the MCP integration now appear in version history. They are attributed to the user who made them instead of to “ScopeStack,” and in most cases they were previously not recorded against the account at all.
• Expense revenue is consistent everywhere. On accounts whose payment term includes travel and expense reimbursement in revenue, an expense with a markup could report three different revenue figures on the same project depending on whether you read the Professional Services resource summary, the expense line in a generated V2 document, or anywhere else in the app. All three now compute the same way, treating the percentage set on the expense category as a target margin rather than a markup. Expect previously understated Expense Revenue figures to rise to the correct value on existing projects.
• Pricing by Service export order. The Pricing by Service section of the project summary spreadsheet now lists services grouped by phase and ordered by position within each phase, with unassigned services first, matching the order on the project.
• Approval email attachments. On a project with more than one approver, the Summary and Work Breakdown spreadsheets attached to approval request emails are now generated in isolation from one another, so they no longer overwrite each other mid-write. Previously this could send an approval request without them, or fail the send outright so the approver got no email at all.
• Document deliveries no longer get stranded. A delivery created for a document that had already finished generating could be accepted and then never dispatched, with no error shown. Deliveries now dispatch reliably, a recurring check retries any that still get stuck, and a delivery that later succeeds clears a failure previously shown on its request.
• Documents generate for projects with a removed teammate. If a project had a teammate whose user was later deleted, generating any V2 document for that project failed outright. Generation now succeeds and omits that person from the teammates list.
• Managed Services section on professional services projects. A generated document that shows a Managed Services section only when the project has managed services no longer shows an empty one, with a blank list and zero recurring revenue, on projects that have only professional services.
• HaloPSA connections no longer accumulate a CRM sync error. HaloPSA is a PSA integration, not a source of CRM opportunities, but it was being swept by the recurring opportunity sync and collecting an Opportunity Sync error under Settings > Account > Connected Apps. It is no longer included in that sweep.
• HaloPSA credential expiry is reported. When a HaloPSA connection’s credentials expire or are revoked, the connection is now flagged as needing reconnection and an email notification is sent, instead of the check failing silently.
• HaloPSA and ConnectWise ticket templates. Setting up a push to PSA no longer fails with an unrecoverable error when the PSA cannot return your ticket templates. If a routine background refresh of your boards, templates, and statuses fails, ScopeStack now keeps showing your last known list instead of emptying it.
• ConnectWise revenue forecast with long product names. A product with a long name no longer causes the entire revenue forecast push to fail. The line item description sent to ConnectWise is shortened, and the full product name is kept in ConnectWise’s own description field.
• Data imports report storage failures. If storing your uploaded CSV or XLSX file fails during a data import, you now get an error instead of an apparent success with nothing imported.
• Managing a non file storage connection. Opening a connected app that is not a file storage integration, such as a CRM or PSA connection, no longer triggers a server error from a folder browser that does not apply to it.
• Archived users stay archived. Archiving a user no longer restores their linked contact record, so an archived user no longer keeps appearing in the Sales Executives list or a client’s contacts. Creating a contact or sales executive whose name matches a previously archived one now restores that record instead of failing with a name conflict.
• Duplicate contacts on user changes. Renaming a user or changing their email address no longer creates a second contact record for the same person.
• Single sign-on users get the right email. Adding a user to an account that uses single sign-on now sends them a notice that they have been added and should sign in with their usual company credentials, instead of an invitation to set a ScopeStack password they cannot use.
• Sign-in page with an empty email. Continuing from the sign-in page without entering an email now shows a message asking for one, instead of moving on with no explanation.
• Project duplication reliability and wording. A duplication request could occasionally be accepted without the copy ever being created, with no error shown. That race is fixed. The confirmation message now says the duplicate is being prepared and will appear shortly, rather than implying it already exists, and the projects list no longer reloads the page when you request one.
• Unified approval workflow, ad-hoc approvers. If your account uses the unified approval workflow, an approver added ad hoc to a step was not counted toward that step’s completion. Depending on the step, that meant it could finish without their decision, or — where the step had only ad-hoc approvers — never complete at all. Ad-hoc approvers are now counted, and approvers marked required are enforced by identity rather than by count alone.
• Screens no longer fail on an account with no saved settings. On an account that had never saved its account settings, the Sales approval level screen and the new project editor screen could fail to load. Both now treat absent settings as empty.
• Clearing a markup on a vendor quote. Clearing the markup or recurring markup on a vendor quote left the field empty rather than zero, which broke that quote’s pricing calculation. An empty markup is now treated as zero.
• Error messages across Admin. When saving, adding, updating, or deleting a record in Admin fails validation, you now see the specific reason, such as a name already being in use, instead of a generic failure message. Bulk actions name which records failed and why, instead of reporting only a count.
• Signing out is faster on accounts that have been active a long time, and expired sign-in tokens are now cleaned up automatically.

Getting Help

Have questions about any of these? Our Support Team is here to help.

📧 support@scopestack.io 📚 Visit our Help Center