Deployment settings are hard to trace
Application services, storage, sign-in, AI, and backup responsibilities are often reviewed separately.
IT and security
Administrators can review deployment settings, configure sign-in and permissions, choose an AI provider, manage review settings, and export organisation data.
Common problems
IT and security teams need to see what is configured and where responsibility sits.
Application services, storage, sign-in, AI, and backup responsibilities are often reviewed separately.
Organisation roles, project membership, document restrictions, and identity mappings can drift apart over time.
The provider, available context, and review process all need to be checked before AI is enabled.
In TOW
Deployment, access, and AI have separate settings so each area can be reviewed on its own.
See the active deployment mode, public endpoint, application service, and storage settings in the admin area.
Set up Microsoft Entra ID, Okta, Google Workspace, Active Directory, or a generic SAML or OIDC provider.
Choose the organisation provider, review its endpoint and models, and check whether an API key is configured.
Before deployment
TOW provides security and deployment settings, but your organisation still decides how to meet its certification, residency, backup, and operating requirements.
FAQ
Current product, deployment, and commercial boundaries.
TOW includes OIDC provider settings and attribute mapping. You should check your provider, claims, and login policy as part of deployment planning.
Yes. Administrators can set the provider endpoint and model, check credential status, or disable AI. Self-hosted teams are responsible for the provider they choose.
No. An export gives you a portable copy of organisation data. Backup, restore, retention, recovery targets, and testing need their own plan.
See TOW in your environment