Tray.io SSO Setup, Plan Requirements and Login in 2026
Oct 27, 202613 min read
Tray.io SSO is a login layer that lets people sign in to Tray with the credentials their company's identity provider already manages.
Tray's documentation ties it to a plan and to admin setup rather than treating it as a default feature, much as other automation platforms such as Activepieces treat single sign-on as something an administrator configures deliberately.
Every claim here comes from Tray's own pages as they stood on 27 October 2026.
Your contract, not this article, decides which features your account includes.
Tray.io SSO Definition and the Direct Answer
What Tray.io SSO is in one paragraph
When a user opens Tray under single sign-on, they are sent to the company's identity provider, prove who they are there, and return to Tray signed in. Tray doesn't hold a separate password for that person.
The consequence is that access control moves to the identity provider: disable someone there and their sign-in path to Tray closes.
Nothing happens until a Tray admin configures the connection, and Tray's docs indicate the feature isn't available on every plan.
So the practical questions are which plan you hold and who on your side can set it up, and the second is the one teams tend to discover late.
You will meet three terms through the rest of the article. The short definitions below show where login ends and account management begins. Take from them that SSO alone doesn't create or remove accounts.
- Identity provider: the system that holds your users and verifies them, such as the directory your company already runs for email and staff apps.
- SAML: the standard message format the identity provider and Tray use to pass the "this person has passed verification" result between them.
- SSO versus provisioning: SSO governs login; provisioning (the job SCIM does) creates, updates and removes user accounts. You can have the first without the second.
Which Tray pages this article relies on
Every Tray statement here comes from Tray's own documentation and plan pages, read on 27 October 2026 and not from third-party summaries. Where a page doesn't state a plan requirement, a price or a limit, this article says so rather than filling the gap.
Everything below works on Activepieces' free plan. Start without code or a credit card.
How Tray.io SSO Login Works Step by Step
To get there, you go through four stages. You confirm you have permission to configure SSO, create an app in your identity provider, paste that app's details into Tray, and sign in as one test user before you require it of anyone.
Stage 1: Confirm admin rights and the plan
Before touching either system, check two things: your Tray account holds an administrator role for the organization, and your contract includes SSO.
When the plan lacks SSO, the settings may simply not appear, which is why the plan gate is the one that stalls rollouts.
Ask your Tray account contact to confirm in writing, and compare their answer with Tray's current documentation page, dated the day you read it.
You also need administrator access to your identity provider (Okta, Microsoft Entra ID or similar), since you'll create an application there. This stage leaves you with a yes or no on entitlement and the right people in the room.
Stage 2: Create the app in your identity provider
In your identity provider, add a new application for Tray using the protocol Tray's documentation specifies. Tray supplies the values the provider asks for, typically a sign-in (callback) address and an entity identifier.
Copy them exactly from Tray's docs or settings page, as a single wrong character produces a generic failure later.
Assign only your test user to the app for now. When this stage is done, the provider has an app that can issue sign-in assertions, but nothing in Tray uses it yet, so no one's login changes.
Stage 3: Enter the identity provider details in Tray
Open Tray's organization security or SSO settings and enter what the provider generated: usually a sign-in URL, an issuer or entity ID, and a signing certificate or metadata file.
This article hasn't confirmed Tray's exact field labels, so match them against the live screen rather than against any name given here.
Save the configuration but leave enforcement off. Password login continues to work, which means a mistake here can't lock out your administrators.
Stage 4: Test with one user before enforcing
Sign in as the assigned test user, using the identity provider route rather than the password form. Success means landing in the correct Tray organization with the expected permissions. Also try a user without an assignment to the app and confirm the provider refuses them.
Only then widen the assignment, and enforce SSO last.
Keep one administrator on password login until enforcement has held for a few days.
Plan, Price and Limits for Tray.io SSO
As of 27 Oct 2026, Tray publishes no price for SSO on its own pages, but it does say SSO is included in Enterprise and available as an add-on on Team. Your contract settles which plan unlocks it, and that's the document to check before you test anything.
What Tray publishes and what it does not
Open Tray's pricing page and it is built around contacting sales rather than listing tiers with amounts.
Tray's public pages say SSO is included in Enterprise and available as an add-on on Team, though they publish no price for it. That is the cost to you.
The setup is documented, and so is the plan; the price is not. Tray's documentation describes how an administrator configures SSO through your identity provider, and says SSO is available on Enterprise plans or as an add-on. So the setup steps tell you what an admin will do, not what your plan includes.
The setup is documented; the plan is not.
Ask your Tray account contact for three things in writing: the plan name that includes SSO, and whether the plan includes provisioning of users from your identity provider. Also ask whether workspace or seat count limits either.
Compare SSO requirements and availability
To see which cells are public and which need a quote, read the table, which sets Tray's published position beside a second platform's. Read "not published" as a task for your account contact, not as a "no".
| Tray | Activepieces | |
|---|---|---|
| Plan required for SSO | Enterprise (included), or add-on on Team | Price not published; confirm with Tray |
| Hosting | Cloud | Cloud or self-hosted |
| Published price | Not published | See Activepieces' own pricing page |
| Provisioning support | Not published | Confirm in its documentation |
Where Tray's cells are empty of public detail, your negotiation has more room, and your risk is greater, because the entitlement exists only if the contract says so.
This table reflects what was checked on 27 Oct 2026.
Before you commit, re-read each vendor's pages and save a dated copy. Make sure the SSO entitlement appears in the signed order form rather than only on a web page.
Easier to see it running than to read about it: set it up free, no card.
Common Tray.io SSO mistakes and fixes
Guard against five mistakes: assuming the plan includes SSO, enforcing before testing, letting a certificate expire, mismatching attributes, and treating SSO as provisioning.
The list below pairs each with its fix and says whether the advice comes from Tray's documentation or from general practice, so you know which parts to verify against your own contract.
- Assuming the plan includes SSO: confirm the entitlement in writing before planning the rollout (Tray docs).
- Enforcing before testing: test with a non-admin account first and keep one admin able to sign in another way (general practice).
- Certificate expiry: record the identity provider's signing certificate expiry date and rotate it ahead of time (general practice).
- Attribute mismatch: compare what your identity provider sends with what Tray's setup page expects (general practice).
- SSO as provisioning: plan user creation and offboarding separately from login (general practice).
If enforcement goes on before a test login has succeeded, every admin can end up unable to sign in, including the person who could switch it off. Test with a single non-admin account, then an admin, and only then enforce.
Tray.io SSO certificate expiry and attribute mismatch errors
When your identity provider's signing certificate expires, logins fail on a date nobody remembers setting. Put the expiry in a shared calendar with a renewal owner.
It fails more quietly when attributes mismatch: if the provider sends an email in a different format or field than Tray expects, the user is rejected or mapped wrongly. Compare one real assertion against Tray's setup page.
Assuming SSO covers provisioning and connected apps
SSO proves who someone is at login. It doesn't necessarily create their account, remove it when they leave, or secure credentials stored in workflow connections.
Even where SSO is in place, Dark Reading's summary of a Push Security analysis found 61% of accounts used SSO only, 29% passwords only, and 10% both.
That's not Tray data, but the 10% means a password path often stays open beside SSO, so plan offboarding for both.
A feature seen on a web page isn't an entitlement, and Tray gates SSO by plan. Ask for the SSO line in the signed order form, with the date you checked Tray's pages saved beside it.
Checklist for Confirming Tray.io SSO on Monday
Before anyone enforces SSO, five steps need finishing, and the written order-form line is the first of them.
- Get the SSO terms from Tray in writing. Ask which plan includes SSO, whether setup is self-service or done by Tray staff, and whether any identity providers are excluded. A sales call isn't evidence, whereas an email or order-form clause survives a change of account manager. Save it beside the date you checked Tray's pages.
- Name the identity provider owner. The identity provider (IdP) is the system that holds your staff logins, such as Okta or Microsoft Entra ID. Tray can only be configured to trust it, so the person who administers it has to make the changes on your side. If nobody owns that, the setup stalls at the first request for a metadata file or an attribute mapping.
- Schedule a test window. Pick a time when the people who can fix a failed login are at their desks, and enable SSO for a small group before the whole workspace. A mistake in the configuration then locks out a few testers instead of every person running a live workflow.
- Create a break-glass admin. This is one administrator account that can still sign in without the IdP, with its credentials stored where two named people can reach them. If the IdP has an outage or a bad configuration change, this account is how you get back in and switch enforcement off. Confirm with Tray that such an account is permitted once SSO is enforced, because the answer depends on the plan and the settings.
- Diarise certificate renewal. The certificate that signs the IdP's assertions expires, and when it does, every SSO login fails at once. Put the expiry date in a shared calendar with a reminder well ahead of it, and assign the renewal to the person named in step two.
Once these five are done, enforcement becomes a routine switch you can reverse. If you can't complete one of them, that gap, rather than the licence price, is what should decide whether you proceed.
What Activepieces does about this
The problem in this article is that Tray's SSO entitlement is decided by a plan the public pages don't name, so you find out what you bought only after you've committed. Activepieces handles it by putting more of the answer where you can read it.
The core is MIT-licensed, so you can clone the repository and run it self-hosted, or air-gapped, before you sign anything. Your security reviewer then doesn't have to rely on a vendor's word for how the product behaves.
What changes is how you test it.
Because you can stand up your own instance, you can run the four stages from earlier against a throwaway environment: create the app in your identity provider, enter its details, sign in as one test user, and refuse an unassigned one.
All of that happens before any contract is signed and before any production login is touched. Activepieces also offers cloud hosting, so the same rehearsal works without running servers if that suits you better.
Read the enterprise licence terms and the pricing page on the day you decide, and save a dated copy, as you would for Tray. I haven't confirmed here whether provisioning is included in a given edition, so ask for that line in writing too.
Check also that the licence for the feature you need is the one in your order form, because the open-source core and the enterprise edition are licensed separately.
Frequently asked questions
Does Tray.io support Okta, Microsoft Entra ID and Google for SSO?
That depends on the supported-provider list in Tray's own SSO documentation, not on a provider's popularity, because Tray's SSO is a login layer that sits on an identity provider. Don't infer support from the name.
Ask Tray to confirm your specific provider in writing, because a provider that uses the same standard protocol isn't the same as one Tray has documented and tested.
Is Tray.io SSO included in every plan?
No. The article's central point is that SSO is gated by plan and by admin setup, so a plan that lacks it can't be fixed by configuration alone.
Read the plan name against Tray's current pricing and security pages, then compare it with the order form in your contract. If the two differ, the contract governs what you can use.
Can I turn SSO off for one user or a service account?
Enforcement is account-wide as documented, so I wouldn't assume a per-user exemption exists.
If a service account or contractor can't sign in through your identity provider, the practical choice is to leave SSO enabled but not enforced. Ask Tray support whether a narrower exception is possible, and get the answer in writing.
Does Tray.io SSO also create and remove users automatically?
Don't assume it does. SSO answers one question: is this person who they claim to be at login.
Creating accounts and removing them when someone leaves is a separate function, usually called provisioning. Check whether Tray documents it for your plan and provider.
If it doesn't, add account removal to your offboarding checklist, because disabling someone in your identity provider may not close their Tray account.
How do I check whether this information has changed?
Treat every Tray statement here as true on the date the page was read, not as a standing commitment. Reopen Tray's SSO, security and pricing pages before you sign and again before renewal, and note the date each time.
Then test with a non-production setup before enforcing.
Where a page and your contract disagree, ask Tray to resolve it in writing before you rely on either.
