The next SpecTacular release: identity, and multi-document projects

Most product updates are incremental. A faster export, a reordered menu, a new colour picker. The release we’re shipping next is not that. It changes what SpecTacular is for.

Until now, SpecTacular has been a way to compose your documents from reusable building blocks. That foundation isn’t going anywhere. But a real engagement produces more than one document, runs through whatever identity stack the customer already operates, and sits in front of reviewers who should not all see the same things. The next release brings all of that inside the product.

Here’s what’s coming, and why each piece matters more than the feature list suggests.

Sign in with the account you already have: OIDC single sign-on

SpecTacular has handled its own usernames and passwords until now. With this release, customers can plug it into the identity provider they already run: Keycloak, Okta, Microsoft Entra, Google Workspace, Auth0, or any standards-compliant OIDC provider.

For employees, that means signing in with the same corporate account they use for everything else. No separate password to manage, no offboarding gap when someone leaves the company. The day a person is removed from the directory, they’re removed from SpecTacular.

For tenant administrators, there’s a dedicated /admin/sso console for configuring providers, mapping identity-provider groups to SpecTacular roles, and inspecting audit events when something goes wrong.

For IT and security teams, this is the access-control story that gets SpecTacular through procurement. Provisioning and revocation happen in the place they already happen, and the audit trail lives with the identity provider rather than in a side-database that has to be reconciled by hand.

The practical effect is that SpecTacular stops sitting beside your identity stack. It belongs inside it.

One engagement, one project, every document in one place

A real project rarely produces one document. A typical consulting or engineering engagement has a specification, a statement of work, a contract, a scope letter, change requests, sometimes acceptance criteria. Until this release, each of those needed its own SpecTacular project, which meant duplicated variables, duplicated reviewer lists, and no single home for the engagement.

That changes. A project becomes a container, and inside it, users create as many documents as the engagement actually has.

Documents are built from two reusable elements:

• Modules, the pieces formerly known as template blocks. Granular, composable sections like a safety clause, a payment milestone, or a data-handling annex.
• Document templates, full document blueprints that can be cloned and customised. A standard statement of work, a standard scope letter, a standard change request form.

Top-level navigation reflects the new model: Projects, Modules, Document Templates, Activity. The project overview is a card grid where each deliverable shows its current status and who owns it. Variables defined at the project level (client name, project code, contract reference, and the rest) flow into every document, so the values stay consistent across the whole engagement instead of drifting from one file to the next.

The day-to-day effect is less duplication, fewer projects to chase across the sidebar, and a single canonical place to look when someone asks “what’s the latest on the Acme engagement.”

Reviewer access, scoped to what they actually need to see

Reviewer permissions used to be all-or-nothing at the project level. The ability to create separate groups of reviewers with or without commenting rights was already a powerful feature, but we did not yet have the ability to bring in a client reviewer, a legal reviewer, or a subject-matter expert, and let them access ony what was relevant to them. So we leveled up…

Reviewer access is now scoped at the document level, with optional restrictions down to specific sections or subgroups within a document.

A few examples of what becomes possible:

• A legal reviewer is given the contract and the data-handling section, and nothing else.
• A client stakeholder is limited to the executive summary and the acceptance criteria.
• An internal subject-matter expert sees only the technical chapter they’re responsible for.
• The same person can hold different access levels across different documents in the same project.

This is what makes SpecTacular safe to use with external reviewers and mixed-audience deliverables. Sensitive content stops leaking through over-broad permissions, and reviewers stop wading through material that wasn’t theirs to comment on. We’ve written before about why external review is where document control falls apart. Granular access is the structural answer to most of the problems described there.

What this release actually changes

Set the three pieces side by side and the picture is straightforward. SpecTacular is becoming a multi-deliverable platform that fits how real consultancies and engineering teams actually run projects.

If your last objection was “it doesn’t fit our identity stack,” that objection is gone.

If your day-to-day pain was duplicating variables and reviewers across five linked SpecTacular projects that should really have been one, that’s gone too.

The underlying authoring model, composing documents from reusable, version-controlled parts, hasn’t changed. What’s changed is the layer above it: identity, structure, and access. Put together, they make SpecTacular something a serious organisation can standardise on, rather than a tool that lives next to one.

If you’ve been evaluating SpecTacular and identity integration or reviewer access has been holding things up, this is the right moment to revisit it. Talk to us about a pilot.