Consolidating Multi-Entity SaaS Stacks: A Unified Digital Workplace

Three separate organisations. Each with its own team, its own operational cadence, its own workflows, its own revenue streams. Sitting under a shared parent consortium that needed them to function as one coherent digital workplace without losing the distinct operational identity that made each one work in the first place. This is the problem that most "virtual office" projects fail to solve — not because the technology does not exist, but because the architecture does not treat the identity layer as the foundation it actually is.

The client — an operating consortium managing an arts and events organisation, a foundation, and a commercial retail entity — came to us with a stack that had grown sideways over time. Google Workspace for email and files. Slack for internal communication. ClickUp for task and project management. HubSpot for CRM. Shopify for e-commerce. And an OpenPhone system handling inbound calls across the group. Every tool worked in isolation. Nothing was connected. There was no single entry point, no unified permissions model, no executive visibility across the three organisations simultaneously.

The brief was to build the platform that fixed this. The client is anonymised here, but the architecture is real — every decision, every configuration, every integration. It applies to any multi-entity organisation sitting on a modern SaaS stack that has never been properly consolidated.

A virtual office platform is not a portal. It is an identity layer. Get the SSO and permissions architecture right first and everything else — dashboards, integrations, workflow automation — snaps into place behind it. Get it wrong and you spend the entire project trying to paper over an access control problem with middleware. Arsalan Faysal — Revenue Systems Architect

Phase 1: What the Architecture Assessment Actually Found

Before any build begins, we document what exists. Not what the client believes exists — what is actually running, how it is configured, and where the gaps are. For a multi-entity organisation, the assessment has an additional dimension: every tool needs to be evaluated not just for how it works within one entity, but for how it interacts with the others.

What we found was a classic ungoverned growth problem. Each organisation had added tools independently as needs arose. Nobody had ever audited what was in place across all three simultaneously, which meant there was significant redundancy, inconsistent naming, and no security posture to speak of at the group level.

The assessment deliverable was a written technical architecture document: current-state diagram, risk register, recommended target architecture, and a sequenced implementation roadmap across five phases. The sequencing was deliberate — identity and access had to be resolved before any integration work began, because every integration decision downstream depends on knowing who has access to what.

Phase 2: Identity and Access Management — The Layer Everything Else Sits On

This is the phase most technology projects either skip entirely or treat as a checkbox. It should be the first thing built and the last thing touched. The identity layer is not a feature of the virtual office — it is the virtual office. Every workflow, every dashboard, every integration is only as secure and as usable as the access control model underneath it.

Google Workspace SSO as the Identity Provider

The decision to use Google Workspace as the central identity provider was straightforward. The consortium was already running Workspace. The domain was established. The email infrastructure was live. The question was not which IdP to use — it was how to structure Workspace so it could govern access across eight tools and three distinct organisational entities simultaneously.

We rebuilt the Workspace configuration from the group level down:

GOOGLE WORKSPACE ORGANISATIONAL UNIT STRUCTURE
------------------------------------------------------------------
[Root Domain — Consortium Group]
  |
  +-- [Org Unit: Arts Organisation]
  |     |-- Users: Art + Events Team
  |     |-- Groups: events@, gallery@, production@
  |     |-- Drive: Shared Drive — Arts Org
  |
  +-- [Org Unit: Foundation]
  |     |-- Users: Foundation Team + External Contractors
  |     |-- Groups: grants@, foundation-ops@
  |     |-- Drive: Shared Drive — Foundation
  |
  +-- [Org Unit: Commercial Retail]
  |     |-- Users: Sales + Fulfilment Team
  |     |-- Groups: sales@, orders@
  |     |-- Drive: Shared Drive — Retail
  |
  +-- [Org Unit: Executive]
        |-- Users: Consortium Leadership
        |-- Groups: leadership@, finance@
        |-- Access: Cross-entity visibility

Organisational Units are the structural mechanism that makes everything else work. Group Policies are applied per OU — the foundation team does not have access to Shopify admin, the retail team does not have access to grant management documents, and executive users have read access across all entities without operational permissions in any. This is not a nice-to-have. It is the security posture that a multi-entity organisation with different legal structures and different data obligations needs to function safely.

SSO Configuration for Downstream Tools

Once the OU structure was confirmed and groups were correctly configured, we connected each tool in the stack to Workspace SSO via SAML 2.0 or OAuth 2.0 depending on what each platform supported. The goal was a single login — one set of Google credentials, all eight platforms.

Phase 3: The Virtual Office Portal — One URL, Everything

The portal is the front door. It is not where the work happens — work happens inside Slack, ClickUp, HubSpot, and the rest of the stack. The portal is where people arrive in the morning, understand the state of the organisation at a glance, and navigate to wherever they need to go. If it requires more than two clicks to reach any tool or any piece of information, it is not functioning correctly.

We built the Virtual Office portal as a role-aware web application hosted on the consortium's domain. The architecture was deliberate: a lightweight Next.js front-end connecting to a Node.js API layer that aggregates data from the connected tools and renders it based on the authenticated user's role and entity membership.

Role-Based Dashboard Architecture

The portal surfaces a different view depending on who is logged in. Executive users see cross-entity revenue and activity. Entity team members see their own operational dashboard. There is no configuration required from the user — the view is derived entirely from their Google Workspace group membership, passed through the authentication token.

Application Launcher and Notification System

Alongside the role-based dashboard, every portal view includes an application launcher — a single-click grid of every tool the user has access to, launched via SSO so no secondary login is required. The notification system aggregates activity from ClickUp (task assignments and due dates), HubSpot (deal stage changes and contact assignments), and Slack (direct mentions) into a single inbox inside the portal. One place to see everything that needs attention, regardless of which tool it originated in.

Phase 4: ClickUp — Five Distinct Operational Workflows in One Platform

ClickUp is the most operationally complex tool in the stack because it has to serve five fundamentally different workflow types across three entities. The failure mode we see most often with ClickUp in multi-entity organisations is a flat, undifferentiated workspace — everything dumped into one hierarchy with inconsistent naming, no templates, and no governance around how tasks are created or progressed. Three months in, the workspace is unusable and the team has reverted to email.

The solution is structural rigour from the first configuration decision. We designed the ClickUp hierarchy around the specific workflow types each entity needed, not around the tool's default feature set.

CLICKUP WORKSPACE HIERARCHY
------------------------------------------------------------------
[Consortium Workspace]
  |
  +-- [Space: Arts Organisation]
  |     |-- Folder: Production Workflows
  |     |     |-- List: Active Productions
  |     |     |-- List: Pre-Production
  |     |     +-- List: Archive
  |     |-- Folder: Repair Workflows
  |     |     |-- List: Pending Assessment
  |     |     |-- List: In Repair
  |     |     +-- List: Ready for Collection
  |     +-- Folder: Gallery Operations
  |           |-- List: Exhibitions Calendar
  |           +-- List: Artist Enquiries
  |
  +-- [Space: Foundation]
  |     |-- Folder: Grant Management
  |     |     |-- List: Prospect Grants
  |     |     |-- List: In Preparation
  |     |     |-- List: Submitted / Pending
  |     |     +-- List: Active Grants
  |     +-- Folder: Foundation Activities
  |           |-- List: Community Events
  |           +-- List: Donor Relations
  |
  +-- [Space: Retail]
  |     |-- Folder: Corporate Sales Pipeline
  |     |     |-- List: Prospecting
  |     |     |-- List: Proposal Stage
  |     |     +-- List: Active Accounts
  |     +-- Folder: Fulfilment Operations
  |           |-- List: Orders to Process
  |           +-- List: Dispatch Queue
  |
  +-- [Space: Executive]
        |-- Folder: Cross-Entity Projects
        +-- Folder: Quarterly Planning (Rocks)

Every List inside this hierarchy uses a standardised Custom Field schema: entity tag, priority tier, assigned owner, due date, linked HubSpot deal or contact (where applicable), and a status field with entity-specific stage names. The standardised schema is what makes the Executive dashboard possible — because every task across every space uses the same field structure, roll-up reporting at the consortium level is clean and consistent.

Workflow Templates

For the three workflow types that recur most frequently — production management, repair management, and grant application — we built ClickUp templates with pre-defined task structures, subtask checklists, and automation triggers. A new production is created from the template in under two minutes and arrives fully structured: pre-production tasks pre-assigned to the relevant team members, stage-change automations configured, and a linked timeline view auto-populated from the production date. The team does not start from a blank task. They start from a system.

Phase 5: The Executive Command Center

The executive dashboard is the reason the entire platform exists from a leadership perspective. Three entities operating simultaneously, each with different revenue models, different production cycles, and different stakeholder obligations. Leadership needed one screen that answered the questions that matter at the top of the organisation without requiring them to log into four separate tools and mentally aggregate what they found.

We built the Command Center as a dedicated executive view inside the portal, pulling live data from HubSpot, ClickUp, and Shopify through authenticated API connections. The design principle was: every metric on this screen maps to a decision. If it does not influence a decision, it does not appear.

The Command Center is not a static report. It is a live operational surface. Every metric is clickable — a revenue figure opens the underlying HubSpot deal list, a production task count opens the ClickUp view filtered to blocked tasks. Leadership can investigate an anomaly in under ten seconds without leaving the portal or logging into a separate tool.

The Integration Layer: How the Stack Talks to Itself

Eight tools. Three entities. One unified platform. The integration architecture is what turns a collection of SaaS subscriptions into a connected operational system. The design principle throughout was minimal middleware — we only introduce a connector layer when a native integration cannot do the job, and we only build a custom integration when the connector layer cannot.

HubSpot and Shopify

This is the highest-value integration in the stack for the retail entity specifically. Shopify customers were not appearing in HubSpot. Purchase history was invisible to the sales team. Customer lifetime value was a number nobody knew. We connected the two platforms via HubSpot's native Shopify integration — available in all HubSpot tiers — and configured bidirectional sync: Shopify customers become HubSpot contacts, Shopify orders create HubSpot deals in the Retail pipeline, and HubSpot contact timeline shows the full purchase history alongside sales activity. The sales team now approaches a corporate account conversation with complete visibility into what that organisation has already purchased.

OpenPhone and HubSpot

OpenPhone connects to HubSpot natively. We configured call logging to fire against the matching HubSpot contact record on every inbound and outbound call. Call recordings and transcripts appear in the HubSpot activity timeline. This eliminated the conversation black hole — every phone interaction is now associated with a CRM record, searchable, and attributable to a specific contact and entity.

ClickUp and HubSpot

The native ClickUp-HubSpot integration handles bidirectional task-to-deal linking. When a deal moves to a specific stage in HubSpot — for example, a corporate sales deal moving to "Won" — a ClickUp task is automatically created in the Retail fulfilment space, pre-populated with the deal details and assigned to the operations lead. No manual handoff. No risk of a won deal sitting in HubSpot while operations has no idea it exists.

The Google Workspace Layer

Workspace is not just the identity provider — it is the document and communication backbone. We configured Google Drive shared folders to reflect the ClickUp hierarchy: every ClickUp folder has a corresponding Shared Drive folder, linked directly from the ClickUp space description. Documents created in the context of a production or a grant application live in Drive, are linked from ClickUp, and are accessible to the correct teams based on their OU membership. No emails with attachments. No Slack messages saying "where is the file?"

What Every Multi-Entity Organisation Learns Too Late

Three things come out of every build like this that are worth stating plainly for the organisation considering one.

The identity layer is not an IT project. It is a business architecture decision. Who has access to what, in which entity, at what level — these are governance decisions before they are technical ones. Getting them right requires the most senior stakeholder in the room, not the most technical one. The OU structure we built reflects actual business boundaries. If you let IT configure this without business input, you get a technically functional permissions model that does not match how the organisation actually works.

Tool consolidation almost never means fewer tools. The instinct when you start a virtual office project is to rationalise the stack — eliminate redundancy, cut subscriptions, simplify. Rarely is that the right outcome. The right outcome is usually the same number of tools, better connected, with clear ownership and access governance. For this client, we did not remove a single tool from the stack. We connected them, governed them, and surfaced their outputs in one place. The platform feels simpler not because there are fewer tools, but because the interface to all of them is unified.

The dashboard is a lagging indicator of the architecture quality. The Executive Command Center looks impressive. It pulls live data from six sources, renders entity-level summaries in real time, and gives leadership a single operational view of the whole consortium. But it only works because the data model underneath it is clean. HubSpot contacts are properly entity-tagged. ClickUp tasks have consistent custom fields. Shopify orders sync to the right pipeline. The dashboard does not create that cleanliness. It reveals it — or reveals its absence. If the underlying configuration is messy, the dashboard will tell you. Build the data architecture first. Build the dashboard last.

If Your Organisation Looks Like This Before the Build

Multiple entities or business units. A stack of SaaS tools that each work fine in isolation and talk to nothing. No central identity layer. Leadership with no consolidated view across the operation. New staff spending their first week figuring out where things live and how to get access to them.

This is not a technology problem. Every tool in your stack has an integration capability. Google Workspace has SSO. ClickUp has an API. HubSpot connects to everything. The problem is that nobody has sat down and designed the architecture that connects them — defined the identity model, mapped the data flows, sequenced the implementation so that each phase builds on the last rather than fighting it.

I build this architecture for multi-entity organisations, consortia, and holding groups running complex SaaS stacks. The engagement starts with a fixed-price architecture assessment: a written current-state review, a recommended target architecture, and a sequenced implementation roadmap. You know exactly what you are getting and what it costs before a single line of code is written or a single integration is configured.

In This Build Architecture Assessment Identity and Access (SSO) The Virtual Office Portal ClickUp — 5 Workflows Executive Command Center The Integration Layer What We Learned Build Yours