There are two ways members can get into Moves+: registering with an email address, or signing in through your organisation's own account with Single Sign-On. This guide explains both, and how allowed email domains work.
Start here: the two routes
Your organisation uses one or the other, not both.
| Email registration | Single Sign-On (SSO) | |
|---|---|---|
| How members get in | They create a Moves+ account with an email address and password | They sign in with the account they already use at your organisation |
| Who sets it up | You, in Settings | Your IT team and OpenPlay together |
| Cost | Included | A chargeable addition |
| Time to set up | Minutes | 1 to 2 weeks |
Turning SSO on replaces email registration entirely. It is not possible to offer both, so members cannot choose. If you are considering SSO, read Single Sign-On for Moves+ before changing anything here.
The rest of this guide covers email registration. The SSO section near the end covers what changes if you move.
The four sign-up types
Set this under Settings, using User Signup Type.
| Option | Restricts who can join | Asks for a reference |
|---|---|---|
| Email Domain | Yes, by email domain | Yes |
| Email Domain (No Reference) | Yes, by email domain | No |
| User Import | Yes, to a list you upload | Yes, checked against your list |
| Email (All Domains Allowed) | No, anyone can join | No |
The two Email Domain options restrict registration in exactly the same way. The only difference is whether members are also asked for a reference.
What the reference is
The reference is your own identifier for that person, such as a student number or a staff number. It is captured at sign-up and stored against the member, so you can match a Moves+ member to your own records.
You control how it is labelled, so it makes sense to your members:
- Unique ID Reference Shown in App is the field label, for example "Student number"
- Unique ID Description Shown in App is the helper text below it, for example "The 8 digit number on your campus card"
Both appear on the sign-up screen, so a clear label here noticeably reduces support queries.
Two things worth knowing before you choose it
- With Email Domain, the reference is not validated. Members can type anything. If you need it to be accurate for matching against your records, use User Import, which checks each reference against a list you upload
- It cannot currently be changed after sign-up. If a member mistypes it, the value stays as entered
If you do not need to reconcile members against your own systems, Email Domain (No Reference) gives your members a shorter sign-up form and fewer ways to get stuck.
Allowed email domains
Set this under Allowed Signup Domains. It applies to both Email Domain options.
Adding more than one domain
You can list as many as you need. Separate them with a pipe character and no spaces:
example.ac.uk|alumni.example.ac.uk|example.org
Members see the list on the sign-up screen, written out as a normal sentence.
How the check works
Moves+ compares the part of the address after the @ against your list, and it has to match exactly.
| Allowed list | Address entered | Result |
|---|---|---|
example.ac.uk |
jo@example.ac.uk | Accepted |
example.ac.uk |
jo@students.example.ac.uk | Rejected, subdomains need listing separately |
example.ac.uk |
jo@example.org | Rejected |
The check runs on the address the member types, not on where their mail actually arrives. This catches people out after a merger or a rebrand. If your organisation still receives mail sent to an old domain, that does not help a member trying to register with their old address. It will be rejected unless the old domain is on the list too.
Choosing your domains after a merger or rebrand
If your organisation has changed name, or merged, you have a genuine decision to make.
Listing only the current domain keeps everything tidy. Every member has one address and one account. Anyone who tries their old address is told which domain to use. The cost is a little friction for members who have not adopted the new address yet.
Listing the old domains as well removes that friction, but introduces a risk worth weighing. The same person can register once with their old address and once with the new one, and Moves+ will treat them as two separate members with two separate point balances. When they later notice their points have "disappeared", the fix is a manual merge.
Our recommendation is to start with the current domain only, and add older ones if you see members struggling. It is easy to add a domain later, and considerably harder to unpick duplicate accounts.
If you use Single Sign-On
SSO is arranged with us rather than switched on in Settings, because it needs configuration on your identity provider as well as ours. It is covered in full in Single Sign-On for Moves+. Here is how it relates to everything above.
What changes
- Email registration stops. Members no longer create a Moves+ password, and existing passwords are no longer used
- Your sign-up type setting no longer governs who gets in. Access follows your identity provider instead, so removing someone there removes their Moves+ access
- There is no sign-up form, so there is no reference field. If you rely on the reference to match members to your own records, raise that with your Client Success Manager before moving to SSO
- Member records are created on first sign-in, not imported in advance. There is no directory sync
Domains work differently under SSO
This is the most important difference, and the one most likely to cause trouble.
SSO routes on a single domain for your organisation, configured by us. It is not the same setting as Allowed Signup Domains, and it does not accept a list. Members whose email is on any other domain cannot sign in through SSO.
So if your members use more than one email domain, perhaps following a merger, raise it with your Client Success Manager before you commit to SSO. It is a solvable problem, but it needs planning rather than discovering at go-live.
It is all or nothing
Moves+ is either SSO or email sign-in for the whole organisation. You cannot give some members one and some the other, and members cannot choose. Plan your member communications on that basis.
Common questions
Can I change the sign-up type after we go live?
Yes. It applies to new registrations from that point. It does not affect members who have already joined.
A member says their email address is being rejected. What should I check?
Check the exact text after the @ against your allowed list, character for character. The most common causes are a subdomain, an old domain from before a rebrand, or a personal address rather than an organisational one.
Can members sign up with a personal email address?
Only if you use Email (All Domains Allowed), or you add that provider's domain to your list, which we would not recommend.
We are moving to SSO. What happens to our existing members?
They keep their accounts, points and history, provided the email address your identity provider sends matches the one they registered with. That matching is the single biggest risk in an SSO rollout, and it is covered in detail in the SSO guide.
Can we turn SSO off again?
Yes. Contact your Client Success Manager. Members return to signing in with an email address as they did before.