🔐Slate's Preferred Partner Login

Technolutions introduced a new method for Slate access with the launch of the "User (Preferred Partner)" user type. It was announced at Slate Summit 2026 and went live in September 2026. The ReWorkflow team has been working with security administrators at Slate schools to convert our existing accounts to this more secure setup. Along the way, we've picked up useful information we'd like to share.

What Changes for Slate Schools

Until now, a preferred partner working in a school's Slate instance typically had one of two user account types:

• User
• User (External)

A "User" account uses login credentials granted through the school's own institutional single sign-on (SSO) and is accessed from the main login page: https://{{school-slate-domain}}/manage/login/

A "User (External)" account starts with an activation password that is sent to the user, who is then prompted to create their own password on first login at https://{{school-slate-domain}}/manage/login/external.

The "User (Preferred Partner)" login works differently:

• The school's administrator creates a user with the Preferred Partner type, or converts an existing one.
• The preferred partner individual user signs in through the preferred partner's own Slate instance, under their company's SSO and multi-factor authentication (MFA).
• Slate connects the two accounts through the User ID, which pairs the preferred partner's Slate database prefix with the person's work email.

For the school, that means:

• No password to create, send, or reset.
• No mobile number to keep on file for MFA.
• When someone leaves the preferred partner, or their login credentials are compromised (a lost or stolen device, for example), the preferred partner disables that one account the moment it knows, and the person's access to every Slate school ends with it. The preferred partner then notifies each affected school so its administrator can deactivate the preferred partner user there as well. The school no longer depends on someone remembering to find and close an External account in its instance.
• A distinct login page at https://{{school-slate-domain}}/manage/login/partner.

Setting Up a Preferred Partner User

The preferred partner sends the school its User ID prefix (a three-character database code) and the work emails of the people who need access.

In Slate, the administrator goes to Database > Users & Access > User Permissions > New User, then:

1. User Type: select User (Preferred Partner).
2. User ID: enter the prefix followed by the preferred partner's Slate instance user ID, with no space. Example: abc:penny.lane@example.com or abc:atargaryen. The user ID alone will not work. Slate needs the prefix to match the user to the preferred partner's Slate database and user record.
3. Name and email: fill in as usual.
4. Active: check "Enable account for access."
5. Role and permissions: set these to fit the scope of the engagement. The sign-in itself works with no role assigned, so the login can be confirmed first and access finalized afterward.
6. Save.

The mobile number can stay blank. MFA happens on the preferred partner's side.

Existing External Users Convert in Place

There's no need to create a second user. Open the existing account, change the User Type to User (Preferred Partner), and update the User ID to the prefixed format. Role and permissions carry over untouched. ReWorkflow's migrations have worked this way thus far with no disruption.

Remember the Test Environment

Slate does not copy new Production users into Test. Either add the same users in Test or refresh it after the Production users are saved.

First-Time Setup for the Preferred Partner

The first time a preferred partner works to establish a partner login, they may need to submit a ticket with Technolutions because a configuration key in the preferred partner's own Slate instance has to be turned on behind the scenes. Once this step is completed by Technolutions, the change takes about 15 minutes to reach every web server, and it's a one-time step. After that, any school can create partner logins for the preferred partner's individual users as needed.

How Partner Sign-In Works

The preferred partner individual user goes to the school's partner login page:

https://{{school-slate-domain}}/manage/login/partner

From there, Slate sends them to their their preferred partner Slate's sign-in page (the address may show slate.technolutions.net for a moment). They sign in with their company credentials, complete MFA, and land in the school's instance.

For Preferred Partners: The User Role Prerequisite

For companies on the partner side, here's the detail that cost our team the most time. Every person who signs in to the schools' Slate instances this way needs Administrator (All Access) in the preferred partner's own Slate instance. Without it, the sign-in to the school's instance fails before it ever reaches MFA.

This permission lives only on the preferred partner's side. The user at the school can keep a narrow role, or none at all, and the login still works.

When the Sign-In Doesn't Go Through

Most errors come down to one setting. Start here:

If none of these resolve it, open a ticket with Technolutions and include the preferred partner's Slate address, the exact error text, the page where it appears, the login address used to start, and the steps already tried. Leave out names, passwords, and phone numbers.

Why This Matters

Slate schools that work with preferred partner companies like ReWorkflow trust us with personally identifiable information (PII). Access to that data must be as easy to close as it is to open. Preferred Partner login gives each school one clean way to grant access and gives preferred partner companies one place to turn it off for everyone at once. Credentials stop traveling by email (or, as Alexander Clark mentioned in the Slate Summit 2026 opening session, sitting in an Excel spreadsheet... gasp!). And it fits what information security teams already expect from outside partners.

Where a school prefers its own SSO (a NetID, sponsored account, or similar), that works too, and ReWorkflow is happy to oblige. What we've retired are shared logins and External accounts, since both are less secure.

For anyone setting this up for the first time and running into something not covered here, we'd love to hear about it. And we'll work to keep this page current as the feature grows.

Frequently Asked Questions

Questions we hear most often from IT and information security leaders reviewing this setup.

Can the school turn off a preferred partner's access on its own?

Yes. The preferred partner can shut off access everywhere at once, but the school never gives up its own control. A school user with the Security Administrator permission can clear the Active setting on the Preferred Partner user at any time, and that person's access to the school's instance ends regardless of what happens on the preferred partner's side.

The two work together. When a preferred partner revokes someone's access on its side, it should tell every affected school so each one can deactivate that user too. ReWorkflow sends that notice every time, so a school's user list never shows an active account for someone who no longer has access.

What happens if the preferred partner's own accounts are compromised?

A great question, since one place to turn access off is also one place to protect. Every Preferred Partner sign-in runs through the preferred partner's own SSO and MFA. Because one account controls access to every school, a departing or compromised account can be cut off in a single step, without waiting on each school to act.

At ReWorkflow, the moment someone leaves or reports a lost device, their account is disabled and their access to every school ends with it. ReWorkflow then notifies each affected school so its administrator can deactivate the Preferred Partner user on the school's side as well.

Schools can add their own layer by giving each Preferred Partner user only the roles and permissions the engagement needs. All preferred partners should be ready to explain how their sign-in is protected and how quickly it can disable an account.

Administrator (All Access)? Does the partner get full admin rights in our instance?

No. That role is required only in the preferred partner's own Slate instance, as part of how Slate verifies the sign-in. It grants nothing in the school's instance. What the person can see and do at the school is set entirely by the roles and permissions the school assigns to the Preferred Partner user, and the login works even with none.

Can activity be traced back to an individual person?

Yes, and that's one of the main reasons shared logins are strongly advised against. Each Preferred Partner user is a separate account in the school's instance, tied to one person's work email. Activity belongs to that individual rather than to a login several people pass around.

How does this compare to giving partners an account on our own SSO?

Both are solid options, and ReWorkflow supports either one. A school's own SSO (a NetID, sponsored, or affiliate account) makes sense when institutional policy requires users to comply with the school's identity system, when access depends on a VPN, or when the security team wants every sign-in in its own logs. Preferred Partner login makes sense when the school would rather not issue and maintain institutional accounts for outside partners, while still keeping individual accounts and MFA in place.

Does this satisfy FERPA and our vendor access requirements?

Only the school's own review can decide that, and this article isn't a compliance determination. What Preferred Partner login does provide are the controls those reviews typically look for: individual accounts, MFA on every sign-in, no shared or emailed passwords, and quick deactivation from either side.

How should we review who has access over time?

Treat Preferred Partner users like any other access review. Check them at the end of every engagement and again during cycle resets, and deactivate anyone who no longer needs access. A simple user query filtered on User Type makes the list easy to pull.

Can any outside company use Preferred Partner logins?

No. Technolutions describes User (Preferred Partner) as a user type reserved for Preferred Partners, meaning companies in its Preferred Partners Program. It also requires a preferred partner Slate instance, which from our understanding is only given when a company joins the preferred partner program. For anyone else, a User (External) account or the school's own SSO remains the path.

Can Silver-level preferred partners use Preferred Partner logins with their only having a Slate test environment?

We assume they can because the test environment has a a three-character database code, but we haven't confirmed this yet. There is a lot of Slate login architecture that doesn't support test environments or relies on the production environment to handle the authentication so we won't assume at this point that it will work. It also might require a different prefix such as abc-test:{{user-id}}. We'll make sure to update this article when we learn more.