Evaluating one point tool is a contained job. You check whether it does its one thing well, whether it signs in through your identity provider, and whether security can live with it. An all-in-one platform asks for more, because it will sit at the center of how many teams work. A weak spot in one module is no longer one team's problem, and a gap in the permission model is a gap across the whole company.
We build Atlas, an all-in-one AI work platform, so we have an interest here. That is why this checklist includes the questions that are hardest for us, and why each section ends with where Atlas stands today.
Why is an all-in-one platform evaluated differently?
Three things change. The blast radius grows: one platform holds customers, contracts, plans, and documents, so access mistakes reach further. Breadth competes with depth: a platform with many modules will be shallower than the best specialist in some of them, and you need to know which. And the exit gets harder: the more work lives in one place, the more it matters that you can get it all out.
A good evaluation tests those three directly instead of scoring a long feature grid. Feature grids reward breadth and hide all three risks.
What should be on the checklist?
| Area | What to ask | Red flag | Where Atlas stands |
|---|---|---|---|
| Identity | Which single sign-on standard? Is provisioning automatic, including groups? | SSO only on request, or no provisioning | SAML SSO and SCIM 2.0 including groups, on paid plans. No OIDC. |
| Permissions | Is there one role model across every module? Can we define custom roles? | Each module has its own sharing rules | Role-based access across 16 modules, custom roles, group-to-role mapping |
| Audit | Are actions by people and by AI in one log? Can we verify it was not edited? | Separate logs, or none for AI actions | One workspace audit log with a Verify chain check, on paid plans. No SIEM stream. |
| AI controls | Can we limit what agents do, require approvals, and cap spend? Is our content used for training? | An assistant with the user's full access and no approval step | Agent governance with approvals and spending caps. No training on your content. Bring your own model. |
| Data protection | Is there data loss prevention? Where is data hosted? | Vague answers on hosting | DLP on higher tiers. Managed cloud hosting with no choice of region. |
| Integration | Is there a documented API? Which connectors work today, not on the roadmap? | A long logo wall with no status | REST API with OpenAPI spec, webhooks, MCP server. 3 connectors available, 3 in beta, 21 in development. |
| Assurance | Which audit reports and certifications do you hold? Is there an uptime SLA? | Claims you cannot see a report for | No SOC 2, no ISO 27001, no third-party audit, no uptime SLA. |
| Exit | How do we export everything, and in what format? | Export only by support ticket, or no stated policy | A published data export policy and a DPA |
The last column is deliberately unflattering in places. Ask every vendor on your list to fill in the same column in writing. A vendor that will not write down its gaps will not tell you about them later either.
How do you run the evaluation?
- Write down the hard requirements first. Certifications, hosting region, contract terms, and regulated data rules. If a vendor fails one of these, stop there. It saves everyone weeks.
- Pick the two or three modules that matter most. For most companies this is the CRM, project tracking, or documents. Test those for depth against the specialist you would otherwise buy. Accept "good enough" in the rest.
- Run a pilot with one real team. Real records, real deadlines, for long enough to cover one full cycle of their work. A demo shows what the product can do. A pilot shows what your people will actually do with it.
- Connect your identity provider during the pilot. Set up single sign-on, provisioning, and group-to-role mapping before you judge anything else. Many permission problems only appear once real groups are mapped.
- Try to break the permission model. Create a user who should see a project but not the contract linked to it. Check search, the assistant, links, and exports. Each one should respect the rule.
- Run an exit drill. Export the pilot's data and open it in another tool. If you cannot get the work out cleanly during a pilot, you will not get it out cleanly in five years.
- Read the audit log together with security. Do a few sensitive actions, including one by the assistant, and confirm each appears with the right person, time, and values.
Which questions do vendors avoid?
Watch for the questions that get a meeting instead of an answer. "Which of your listed integrations can we connect today?" is one: logo walls often mix live connectors with planned ones. "Who can our security team talk to?" is another. "What do you not do that a company like ours usually needs?" is the most useful of all, because a vendor that answers it plainly is telling you how it will behave when something goes wrong. Our earlier piece on what enterprise buyers actually ask for covers the security questionnaire side in more detail.
Where Atlas stands today
Atlas puts 16 modules on one platform: Assistant, Tasks, Projects, Docs, CRM, Inbox, Meetings, Contracts, Forms, Documents, Search, Analytics, Habits, Goals, PDF Studio, and Diagram Studio, which is in beta. It is free to start with one team, and the Enterprise plan has custom terms for a company-wide rollout. The identity, permission, audit, and AI controls in the table are real and on paid plans. You can watch them in the Atlas product tour and read the controls on the security page.
The gaps are just as real. There is no SOC 2 or ISO 27001 report, no third-party audit or penetration test, no uptime SLA, and no choice of data region, single-tenant deployment, or on-prem install. There is no BAA, so health data should stay out. Most listed connectors are still in development. If your hard requirements include any of these, Atlas should not pass step one of your evaluation today, and we would rather you find that out on day one.
Who this checklist is not for
If you are buying one tool for one team's job, a shorter evaluation is fine and this checklist is more than you need. If your company already has a platform at its center that works, the better question is how to connect the gaps, not how to replace it. And if your procurement process requires a certification before a pilot can start, read the vendor's trust documents first and skip the pilot until that box is checked.
What is the most important test for an all-in-one work platform?
The permission model across modules. One platform holds many teams' work, so a single role model that search, the assistant, links, and exports all respect matters more than any one feature.
Should an all-in-one platform match specialist tools in every module?
No. Test depth in the two or three modules your company relies on most, and accept good enough in the rest. The gain from one platform is the shared data and permissions, not winning every feature comparison.
How long should an enterprise pilot run?
Long enough to cover one full cycle of the pilot team's work, such as one sales cycle or one project phase, with real records and the identity provider connected.
Does Atlas hold SOC 2 or ISO 27001?
No. wrxstack holds no SOC 2 or ISO 27001 report and has had no third-party audit. The controls Atlas has, such as SAML SSO, SCIM, custom roles, audit logs, and DLP, are product features, not certifications.
How do we test data portability before buying?
Run an exit drill during the pilot: export the pilot team's data, open it in another tool, and check that records and their links survived. Read the vendor's written export policy as well.
Can we start an Atlas evaluation without talking to sales?
Yes. Atlas is free to start with no credit card, so one team can pilot it on real work. Contact sales when you are ready to discuss Enterprise custom terms.
Where this lives in wrxstack: the Trust Center and Atlas.