Single Sign-On for Your Team: Okta, Microsoft Entra ID and Google Workspace
Let your staff sign in to Seayora with your company’s identity provider over OpenID Connect or SAML 2.0 — verify your domain, test, turn it on, require it, and add new people automatically with the right role.
Let your team sign in to Seayora with your company’s identity provider — Okta, Microsoft Entra ID, Google Workspace or anything that speaks OpenID Connect or SAML. Nothing changes for residents, owners or anybody outside your company.
Single sign-on is for a property management company or a contractor’s business with a team. Only the account owner can set it up, and every change asks for a one-time code first — pointing a company’s sign-in at a different provider would hand that provider every account on the team.
It is under Settings → Single sign-on on the website, and on the iPhone and Android apps under Settings and in the Tools hub as Single sign-on, with Single sign-on activity beside it.
What you need before you start
- Admin access to your identity provider — Okta, Microsoft Entra ID, Google Workspace, OneLogin, JumpCloud or any provider that speaks OpenID Connect or SAML 2.0.
- Access to your company domain’s DNS, to add one TXT record.
- Your own Seayora password. You — the account owner — can always sign in with it, so a broken identity provider can never lock the company out.
Choosing a protocol
| Protocol | Use it for |
|---|---|
| OpenID Connect | Okta, Microsoft Entra ID, Google Workspace, Auth0, OneLogin, JumpCloud and most modern providers. |
| SAML 2.0 | For providers or IT teams that use SAML — ADFS, PingFederate, Shibboleth and the same names above. |
OpenID Connect is the easier of the two: you paste an issuer URL, a client ID and a client secret. Seayora reads the rest from your provider’s published configuration and checks every sign-in’s signature against its published keys.
Step 1 — create the app at your identity provider
Settings → Single sign-on shows the values your provider asks for, each with a Copy button.
- OpenID Connect: create a web application. Give it the redirect URI shown in Seayora, and allow the openid, email and profile scopes. Copy the issuer URL, the client ID and the client secret back into Seayora.
- SAML 2.0: create a SAML application. Give it the Assertion Consumer Service (ACS) URL and the entity ID shown in Seayora (or upload the metadata file from the metadata link). The NameID or an email attribute must carry the person’s email address. Copy the provider’s sign-in URL, its entity ID and its signing certificate back into Seayora.
- Groups (optional): if your provider can send the groups a person belongs to, Seayora can use them to choose a role for new people.
The client secret is kept encrypted and is never shown again — leave the box blank to keep the saved one. A SAML response must be signed; Seayora refuses an unsigned one, one from any issuer other than the one you named, and one more than 2 minutes outside its validity window.
Step 2 — verify your domain
Single sign-on is used for addresses at the domains you verify. Verifying proves your company controls the domain: add the TXT record shown to its DNS, then check it here.
- Add your domain (for example acmeproperties.com). Seayora shows a TXT record that starts with seayora-sso-verification=.
- Add that record to your domain’s DNS, then press Verify. DNS changes can take up to an hour to appear.
- A connection can have up to 10 domains.
- That domain is a public email service. Anybody can open an address there, so it cannot be claimed for a company’s sign-in.
- That domain is already verified by another Seayora account. If it is yours, contact support.
A domain routes nobody until it is verified, so adding the wrong one by mistake changes nothing.
Step 3 — run a test sign-in
Test sign-in opens your identity provider and shows what came back. Nobody is signed in by a test, and it works while the connection is still in Testing.
The result is saved on the settings page: the address your provider sent, the name, the groups, and — if it failed — the reason in plain words. Changing anything about the provider afterwards means running a new test before single sign-on can be turned on.
Step 4 — turn it on
| Status | What it means |
|---|---|
| Draft | Being set up. Nobody signs in through it yet. |
| Testing | Only "Test sign-in" uses it. Everybody else signs in the usual way. |
| On | Your team signs in with your identity provider when they type an address at a verified domain. |
| Off | Switched off. Everybody signs in the usual way, and the settings are kept. |
It can be turned on once the identity provider is saved, at least one domain is verified, and a test sign-in has worked with the current settings. Once it is on, the sign-in page offers “Continue with” your provider’s name to anybody who types an address at a verified domain, and the apps offer “Sign in with your company”.
Requiring single sign-on
| Choice | What happens |
|---|---|
| Offer it | Single sign-on is offered at sign-in; a password, Google, Apple or a passkey still works. |
| Require it | Team members at a verified domain must sign in with your identity provider. Their password, Google, Apple and passkey sign-in stop working on Seayora. |
Before requiring single sign-on, make sure a test sign-in worked. You — the account owner — can always sign in with your password, so a broken identity provider can never lock the company out.
- When it is required, a team member’s password, emailed code, Google, Apple and passkey sign-in are refused with a sentence telling them to sign in with your provider, and a button that does it.
- You can sign everyone on your team out when you turn it on, so they sign back in through your provider straight away.
- Turning single sign-on off also stops requiring it, so nobody is ever left with no way in.
- Residents, owners, outside contractors and anybody else who is not on your team are never affected.
Adding new people automatically
When on, a person at a verified domain who signs in through your identity provider and is not yet on your team is added to it with the role below. When off, only people already on your team can sign in this way.
Somebody new is shown your company’s name, the role they will have, and the Seayora agreement, which they must accept before the account is made. They join with the permissions your team settings give that role.
Roles for a property management company
| Role | What it is for |
|---|---|
| Manager | Runs the day to day. Everything except the company’s own billing and bank. |
| Leasing agent | Fills vacancies. Listings, applicants and showings — not the books. |
| Maintenance coordinator | Runs repairs, inspections and equipment. No money, no leases. |
| Bookkeeper | The books, rent and reporting. No residents, no leases. |
| Staff | General office work. Reads most things, changes the operational ones. |
| Viewer | Read-only across the operational side. Cannot change anything. |
Roles for a contractor’s business
| Role | What it is for |
|---|---|
| Manager | Runs the business day to day. Everything except the bank and billing. |
| Dispatcher | Assigns the crew and keeps the board moving. No pricing, no books. |
| Estimator | Prices work and sends quotes. Reads jobs, does not dispatch. |
| Bookkeeper | Invoices, books and payroll. Reads jobs for context only. |
| Technician | Does the work. Their own jobs, their own hours, nothing else. |
| Viewer | Read-only. Cannot change anything. |
Group rules choose a role from the groups your provider sends — one rule per line, a group name, then = and a role (for example “Leasing team = leasing”). The first rule that matches decides the role; with no match the default role is used. Up to 20 rules.
You can also ask the provider to make people sign in again every time, rather than reusing a session they already have open there.
Who is never signed in this way
- Seayora staff accounts cannot sign in through a customer’s identity provider.
- This address belongs to another company’s team on Seayora, so it cannot sign in through this identity provider.
- Your identity provider says this email address has not been verified, so it cannot be used to sign in.
- Your identity provider signed in an address at a domain this connection has not verified.
Activity
Every change, domain check, test, sign-in, refusal and person who joined is listed under Activity, newest first, with who did it and when.
| Entry | Means |
|---|---|
| Connection created | The connection was first saved. |
| Settings changed | A setting changed. If it was the provider, a new test is needed before it can be turned on. |
| Turned on or off | It was turned on, off, or into testing. |
| Requirement changed | Requiring it was switched on or off. |
| Domain added | A domain was added. It routes nobody until it is verified. |
| Domain removed | A domain was removed. |
| Domain verified | The DNS record was found, and the domain now routes sign-ins. |
| Domain check failed | Verify was pressed and the record was not found yet. |
| Test sign-in worked | A test sign-in worked. Nobody was signed in by it. |
| Test sign-in failed | A test sign-in failed, with the reason. |
| Signed in | Somebody on the team signed in through your provider. |
| Sign-in refused | Your provider signed somebody in and Seayora refused them, with the reason. |
| Added to the team on first sign-in | Somebody new accepted the agreement and joined your team. |
| Password sign-in refused (single sign-on required) | A team member tried another way in while single sign-on is required. |
| Connection deleted | The connection was deleted. |
Troubleshooting
- “This link has expired” on the join page: the link lasts 15 minutes. Sign in with your company again.
- “That sign-in took too long or was already used. Please start it again.” A sign-in has 10 minutes to come back from your provider, and each one works once.
- The domain will not verify: check the TXT record is on the domain itself, not a subdomain, and that it matches exactly. Some DNS hosts add the domain name to the record name for you.
- A test says the email is missing: in your provider, make sure the email claim (OpenID Connect) or the NameID or email attribute (SAML) is sent. If your provider uses its own name for it, put that name in Email attribute.
- You are locked out of your provider: sign in with your own Seayora password and turn single sign-on off. Your team can then sign in the usual way.
Asking your assistant
Single sign-on is not on Seayora’s connector for Claude or ChatGPT. It is a security setting for the account owner, every change asks for a one-time code, and a connected assistant should never be able to change how a whole team signs in.
Related features and guides
- Single Sign-On (SSO) — Feature. Single sign-on with supported providers, so your team authenticates through your existing identity provider instead of another password.
- What Seayora Records About Your Use of Third-Party Services — Documentation. Seayora meters the outside services your account uses — models, email, text messages, maps, identity checks — so it can budget for them. What is counted, what is not, and what it is never used for.
- Privacy choices in the mobile app — Documentation. What agreeing on first launch turns on, what each one collects, and how to turn either off.
- How we know whether an email reached you — Documentation. What the tracking image in a Seayora email does, what it can and cannot tell us, why an "open" is not the same as a read, and how to turn it off.
- Team Roles & Permissions (RBAC) — Feature. Role-based access control with employee accounts, so leasing agents, maintenance staff, and bookkeepers each see only their scope. Every action is audit-logged.
- Employee Tasks & Check-Ins — Feature. Assign tasks to staff, track completion, and require check-ins at site visits so field work is accountable rather than assumed.