What it is and what it's for#
Onboarding one person is easy. Onboarding six hundred on the same Monday is not, and the problem is almost never creating the accounts: it is that each one comes in with the right location, the right organisational unit and the right group. An incomplete record raises no error anywhere; that person simply opens the app and sees next to nothing.
This page covers the operational detail of the launch. The onboarding routes and the record fields are in Users and access.
Before onboarding anyone, the structure has to exist: locations and organisational units created and with their final code. If people arrive with codes that do not yet exist, they come in with no segmentation and have to be reviewed one by one. See Getting started.
How to set it up#
1. Prepare the list of expected emails#
It is a list of the addresses you expect, drawn up before people come in. It does not create accounts: it is there to keep the expected headcount in one place and see afterwards who has come in and who has not.
It is kept in Pre-Users (the screen is titled Expected sign-ups): each address is added with Add email address, and the list gives you the status of each one: Not signed up, Signed up, Deactivated or Empty. The address has to be exactly the one the person will use to sign up.
That is the screen's real use: in Status, pick Not signed up and you have, without asking anyone for reports, the list of who is still to come in.
Being on this list does not grant access on its own. Who can register is decided by the company's allowed domains.
2. Onboarding in bulk#
When ten or fifteen people come in at once and you already know their details, add them one by one with Add person in Users: each record needs at least First name, Email and Password, and right there you choose their Structure, Location, Tribe and Eligibility groups.
For larger volumes, the load of people is prepared in a file with the WinChange team: the panel has no file upload for people. What can be loaded from Excel are the locations and the organisations, with Download Excel and Upload Excel in Locations and Organisations: that way the structure is ready, with its codes, before the load.
3. Eligibility groups#
An eligibility group is a label that groups people by a criterion of your own that is not in the org chart or in the map of sites: a collective, a rollout wave, a professional profile, the team on a particular programme.
It serves the same purpose as the location or the unit: deciding who receives actions, surveys and team challenges. The difference is that you define it, with whatever logic you need.
- They are created in User Eligibility Groups, with Add group: Name, Description (only admins see it), Group active and, under People in the group, the people who belong to it, with a search by name or email.
- They can also be assigned from the person's record, under Eligibility groups.
- It takes several per person: someone can belong to two collectives at once.
- The list shows how many people each group has and where it is used. A group that is not used can be removed with Delete (it cannot be undone); one that is in use cannot: it is switched off, keeps what it already has and can no longer be added to new actions, surveys, challenges or people.
4. Check before opening the app#
- 1
Codes that match
Each person's location and organisational unit, with the same code you configured. It is failure number one.
- 2
Managers in place
A Manager on every organisation and every site, or those people will not show up in anybody's dashboard and the approval-based actions will be left hanging.
- 3
A real test
Onboard two or three people with different profiles and sign in as them before opening to everyone. It is the only way to see what they are going to see.
What happens next#
- The employee sees none of these screens. They are admin only.
- Appearing on the list of expected emails does not create the account. The account is born when the person registers or when you onboard them.
- As soon as the record exists and is active, the person enters the content distribution: they receive the actions that correspond to their segmentation, as long as those actions have the Nuevas altas en la plataforma (new sign-ups) rule ticked in their assignment step.
- When someone registers, their row on the expected list moves to Signed up. That is where you see the progress of the onboarding campaign.
- Correcting someone's location afterwards changes what they see, and also who approves them. It is not a minor change halfway through a programme.
Frequently asked questions#
Do I have to put people on the expected list if I am going to onboard them myself afterwards?
No. They are two independent things. The list is a control headcount; onboarding is what creates the account.
What happens if the same email appears twice on the expected list?
Nothing stops it, but it muddies the count. The Duplicated button in Pre-Users finds them.
I cleared Active on an expected address. Can that person no longer get in?
They still can. That tick box blocks nothing: it neither prevents sign-up nor revokes access for somebody who already has an account. To remove someone's access, untick Can sign in on their profile, in Users.
Do eligibility groups replace the location?
No, they add to it. If an action is segmented by location and by group, the person has to meet both conditions to receive it. Note that team challenges work the other way round: anyone who meets any of the ticked criteria joins the team.
Can I move a lot of people to another group at once?
Yes, from the group's form in User Eligibility Groups: under People in the group you tick or untick each person without opening their profile.
I onboard someone halfway through a journey. What do they receive?
The live actions for their segmentation that have the Nuevas altas en la plataforma (new sign-ups) rule ticked. If they use dates relative to the assignment, they start from the beginning from their own date; if they use fixed dates, they join at the point the rest have reached.
Limits and warnings#
- A misspelled address on the expected list raises no error. It is saved all the same and that row never moves to Signed up; the problem shows up days later, when someone says they can't see anything.
- A group in use cannot be deleted. To retire it, switch it off: whatever it already has assigned stays. Deleting an unused group cannot be undone.
- Changing who is in a group does not hand out actions straight away. The group's form itself says so.
- Onboarding halfway through a campaign does not recover what has expired. Actions whose deadline has already passed do not come back.
- Always start with a small batch. Loading six hundred records with the wrong code costs far more to undo than to check beforehand.