--- title: "Onboarding your institution" summary: "How a signed agreement becomes a working workspace. This covers what we provision, what you supply, and the order the owner should work in on day one." updated: "2026-10-07" section: "Get started" url: "https://zovos.ai/docs-onboarding.html" --- # Onboarding your institution We set Zovos up together with you. There is no self-serve signup and no trial account to create. Onboarding starts with your Zovos contact, and it ends with a workspace connected to your own identity provider and an owner who can bring the rest of the compliance team in. This guide is for the chief compliance officer or program owner running that process at a bank or credit union, whatever its size. Once you are inside, [Getting started with Zovos](docs-getting-started.html) covers the workspace itself and [Set up your team and SSO](docs-team-setup.html) covers ongoing team administration. ## What we provision and what you supply We create the workspace. That means your own database schema, a dedicated key for your stored documents, the identity organization your sign-ins resolve against, and the record of your contracted terms. You do not install anything, and there is nothing to run on your own infrastructure. What we hold and how it is separated is described on the [security page](security.html). Three things have to come from you before we can start: - **Your institution's display name.** This is the name shown in the product and on anything you export from it. - **A short identifier.** It uses lowercase letters, numbers and underscores, begins with a letter, and names your workspace internally. It is **permanent**. There is no rename path once the workspace exists, so pick something you will still recognize in five years. - **Your identity provider administrator.** We need the name and contact details of the person who can create an application in Okta, Entra ID, Google Workspace, or whatever your institution runs. You will need them for the step below. We record your commercial terms against your workspace, so you do not enter them yourself. Those terms are the plan, the contracted seat count and the renewal date. ## Connecting your identity provider Once the workspace exists, we send you a **one-time setup link** for the identity connection. It is short-lived by design, so treat it as a scheduled step rather than something to forward and get to next week. If it lapses before you use it, ask your Zovos contact for a fresh one. That costs nothing but a message. Have your identity provider administrator ready when you open it. Everything the connection needs is entered on that link rather than inside Zovos. That includes the metadata URL or XML, the certificate, the reply and entity identifiers, and the email domains. The product's own single sign-on panel shows the state of the connection and never asks you for a secret. You may want membership and roles to flow from your directory rather than from invitations. If so, we set up directory synchronization with you in the same session. There is no self-serve link for it. What happens *after* the connection exists is yours. Mapping your directory groups to Zovos roles is an in-product screen an owner edits, and it is covered under [Set up your team and SSO](docs-team-setup.html). An owner can also map directory groups to access groups, which bundle roles, job families and a scope. ## Your first sign-in Everyone in your institution reaches Zovos at **https://app.zovos.ai/login**. There is one address, one **Continue with SSO** button, no institution picker and no Zovos password. Your workspace is determined by the identity you sign in with, which is why the link is the same for every customer. The first person in is whoever we map to the owner role on the identity connection. That is normally the CCO or the program owner. Tell us who it is before the connection call, because that person has to sign in before anyone else can be brought in. Invitations are sent from inside the product by someone who already holds the owner role, and an account that has never signed in is not yet active. Examiners do not arrive this way. A regulator gets a time-boxed session, read-only apart from a few fieldwork actions, that an owner issues during an examination and hands over as a one-time token, pasted on the same sign-in page. See [Exam management and audit readiness](docs-exam-management.html) and [Roles and permissions](docs-roles-permissions.html). ## What your network team needs to allow Most institutions need nothing more than normal outbound HTTPS, but corporate proxies and allow-lists sometimes need these named: - **app.zovos.ai over HTTPS on port 443, including the WebSocket upgrade.** The collaborative drafts editor uses a WebSocket on that same host and port. A proxy that strips the upgrade header breaks co-editing in Drafts and nothing else, because the rest of the product is plain HTTPS. - **WorkOS, our identity partner, and your own identity provider.** Signing in is a top-level redirect out to them and back, so both have to be reachable from the browser. - **Our document storage endpoint.** Document uploads and downloads go directly between the browser and object storage rather than through the application. Ask [support](support.html) for the allow-list entry for your environment. Two related facts are worth passing on. Zovos cannot be embedded in an intranet portal frame, because the product deliberately refuses to be framed. An owner can also restrict the whole workspace to a list of your own IP ranges if you choose. That is a real feature, and [Set up your team and SSO](docs-team-setup.html) describes it, including how not to lock yourself out. ## Day one, in order The order matters more than it looks, because several steps are prerequisites for the ones under them. 1. **Set your institution profile and timezone.** Settings ships with generic defaults. They describe a bank under one billion dollars in assets, on UTC, with no charter states recorded. Until you correct the charter type, asset band and states, regulatory-change applicability is being judged against those defaults, and the daily digest and the obligations calendar run on UTC rather than your business day. 2. **Enroll your frameworks.** This is owner-only, and it is the step that scopes everything downstream. Until it is done, the framework library, Citations and the Gap report are all empty. See [Frameworks and citations](docs-frameworks.html). 3. **Invite your second approver and get them signed in.** Critical decisions require two distinct signers, and an invited person is not an approver until they have signed in themselves. See [Set up your team and SSO](docs-team-setup.html). 4. **Give each teammate their job families.** A job family says what a person does, such as compliance, AML/CFT or internal audit, and a person can hold several. Families order the sidebar and choose the dashboard panels for that person. They never grant a permission and never change the price. Set them on the invitation or later on the Team screen. See [Roles and permissions](docs-roles-permissions.html). 5. **Bring in your policies and controls.** Import your control baseline and upload your policy documents so analysis is grounded in your real program rather than a template. See [Policies and document management](docs-policies.html) and [Controls, testing and evidence](docs-controls.html). 6. **Ask your Zovos contact to confirm the regulatory library is indexed for your workspace.** Agents cite the library, and until it is indexed they decline to run rather than answer without sources. Confirm it before the first agent run, not after. 7. **Run mapping on the Gap report, then run the gap analysis.** Mapping is what produces the gaps. The Gap Analysis agent then works against a gap that already exists. Running them the other way round is the most common first-week stumble. Agent output is a proposal and never a decision. See [How AI works in Zovos](docs-ai-in-zovos.html). 8. **Triage the first finding.** Assign an owner, a due date and a root cause, and you have the beginning of a record an examiner can follow. See [Findings and remediation](docs-findings.html). ## Email during onboarding **The product does not send email today.** Notifications are delivered in the workspace, through the bell in the top bar and the panels on the Dashboard. The email preferences in settings record your choices but stay inert until email delivery is switched on for the deployment. The product says so on the screen rather than quietly dropping messages. Plan onboarding on the assumption that nobody gets nudged by email. There is exactly one email in the whole flow. It is the **teammate invitation**, which is sent by WorkOS, our identity partner, from its own sending domain rather than from Zovos. Ask your mail team to let it through before you start inviting people, or your first invitations will sit in quarantine. ## Who does what | Task | Who does it | | --- | --- | | Creating the workspace and recording your terms | Zovos | | Connecting your identity provider | Your IdP administrator, on the one-time setup link | | Directory synchronization (SCIM) | Set up with Zovos during onboarding | | Mapping directory groups to Zovos roles | You, on the Access & SSO tab in Settings | | Assigning job families to teammates | You, on the Team screen or through directory group mappings | | Enrolling frameworks, importing policies and controls | You | | Inviting teammates and granting examiner access | You | | Indexing the regulatory library for your workspace | Zovos | | Recovering an IP allowlist you locked yourself out of | Zovos support | If anything in the sequence above stalls, [contact support](support.html). We prioritize anything blocking an examination.