"Connected" is one of the most stretched words in work software. A tool with an integrations page calls itself connected. So does a bundle of apps sold under one brand. So does a chat tool that can post a message when something changes elsewhere. These are all useful, but they are not the same thing, and the difference decides whether your team can actually answer a simple question like "what happened with this customer?" in one place.
This guide gives a plain definition, a test you can apply to any product, and an honest account of how Atlas fits and where it stops.
What makes a workspace "connected"?
Three things, and a product needs all three.
Shared records. A customer exists once. The deal, the contract, the kickoff project, and the support request all point at that one customer rather than holding their own copy of the name and details. When the record changes, every view of it changes.
Direct links. Records are linked to each other natively: this task belongs to this project, which was created from this deal, which is governed by this contract. The links are part of the data, not a URL pasted into a comment.
One permission model. The same rules decide who can see each record and each link. Without this, connected data leaks: a link from a project you can see to a contract you should not see becomes a way around the rules.
When a product has all three, you can start anywhere and follow the thread. Open a customer and see their deals, open a deal and see its contract and the project it started, open the project and see the tasks and the meeting notes that created them.
What is a work graph?
A work graph is the name for that structure: records as nodes and their relationships as edges. "Graph" here describes the shape of the data, not a particular database. The useful property is that questions which cross record types become simple to ask. "Which open tasks are blocking deals that close this month?" is one question over a graph. Across separate apps it is an export, a spreadsheet, and an afternoon. Our engineers describe the internals in how the work graph is built.
How is a connected workspace different from integrations?
Integrations connect apps that each keep their own data. They are valuable, and every company needs some. But they move copies of data between systems on a trigger, and each copy can drift. The table compares the three common ways teams try to connect their work.
| Approach | Point-to-point integrations | Automation layer between apps | Connected workspace |
|---|---|---|---|
| Where the data lives | In each app, copied between pairs | In each app, copied by workflows | Once, in one data model |
| How records relate | Matched by name or ID field | Matched by rules someone maintains | Linked directly |
| Permissions | Each app's own rules | Usually the integration account's access | One model across every record |
| When something breaks | Silent drift until someone notices | A failed run in a separate tool | No sync to fail between modules |
| Cross-type questions | Export and join by hand | Possible if someone built the flow | Ask directly, in search or the assistant |
| Best for | Two specialist tools that must stay separate | Moving events between systems you cannot replace | The work that crosses teams every day |
These are not rivals. A connected workspace still needs integrations for the systems that stay outside it. The question is which work sits at the center.
What can you do in a connected workspace that is hard across apps?
Follow a customer end to end. One record shows the emails, meetings, deal stages, contract, and delivery tasks, so a new account owner starts from context.
Search once. One query returns tasks, documents, deals, and contracts, filtered by what the person is allowed to see.
Ask an assistant a real question. An assistant can only answer from what it can see. In a connected workspace it can read across record types and cite them. Across separate apps it sees what each connector exposes, one app at a time.
Let an agent act safely. When an agent closes a task and advances a deal, both changes happen in one system under one set of permissions, and both land in one audit log.
Report on the work itself. Dashboards can count across modules without a data pipeline, because the records already share a model.
How can you tell if a product is truly connected?
- Change a customer's name once. Then check the deal, the contract, and the project. If any of them still shows the old name, the data is copied, not shared.
- Follow a link and check permissions. Give a test user access to a project but not to its linked contract. They should see that a link exists only if your rules allow it, and never the contract itself.
- Search across types. Search for a customer name and see whether tasks, documents, and deals come back in one list.
- Ask a cross-type question. Ask the assistant something that spans two modules and check whether it cites records from both.
- Read the audit log. Make changes in two modules and confirm both appear in one log, with the same person attached.
How Atlas connects the work, and where it stops
Atlas is built as one work graph across 16 modules, including Tasks, Projects, Docs, CRM, Meetings, Contracts, and Forms. A deal can carry its quotes, contract, and follow-up tasks, a form submission becomes a task, and meeting action items become tasks. Search covers every module in one query and applies each person's role at query time, and Ask Atlas answers from the same records with citations on paid plans. Actions by people and agents land in one workspace audit log on paid plans.
The limits are real. The graph covers what lives in Atlas. Data from other apps only joins it through a working connector, and today that means Gmail, Google Calendar, and Google Drive, with ZoomInfo, Granola, and Twilio in beta and the other 21 listed connectors in development. Diagram Studio is still in beta. And some modules, including the CRM and Ask Atlas, are on paid plans.
Who a connected workspace is not for
Teams whose work genuinely stays inside one discipline, such as an engineering team that lives in its code host and issue tracker, may not gain much. Companies that must keep a regulated system of record separate should connect to it rather than move it. And if you need deep, specialist features in one area more than you need the links between areas, a dedicated tool for that area may serve you better.
What is a connected workspace?
A connected workspace is a work system where tasks, projects, documents, customers, and agreements are records in one shared data model, linked directly and governed by one permission model, so people and assistants can follow work end to end.
Is a connected workspace the same as having integrations?
No. Integrations copy data between apps that each keep their own records. A connected workspace stores each record once and links records directly, so there is no copy to drift.
What is a work graph?
A work graph is the structure of a connected workspace: records as nodes and their relationships as links. It makes questions that span record types, such as tasks blocking this month's deals, simple to ask.
Why does a connected workspace matter for AI assistants?
An assistant can only answer and act on what it can see. In a connected workspace it reads across record types under one set of permissions, instead of seeing one app at a time through connectors.
Is Atlas a connected workspace?
Yes, for the work inside it. Atlas links records across 16 modules with one permission model and one search. Data from other apps joins only through working connectors, which today are Gmail, Google Calendar, and Google Drive.
Where this lives in wrxstack: the Atlas assistant and Atlas Contracts.