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.
- 1
Add the row
Add new creates an empty row at the end of the list.
- 2
Type the email
The table is edited in the cell itself: you click on Email, type, and leave the cell. The change saves on its own.
- 3
Control the status
The active status column lets you withdraw someone from the forecast without deleting the row.
| Column | What it is |
|---|---|
| ID | Row number. Not to be touched. |
| The expected address. It is the only data you fill in yourself. | |
| Client ID | Fills in on its own as soon as that person registers. Empty means "has not come in yet". |
That self-filling column is the screen's real use: sort by it 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#
On the user assignments screen you work on a table with Name, Email, Status, Country, Organisation Hierarchy and Client ID, editable cell by cell.
The + Add new users button adds an empty record to the project and lets you fill it in right there, without opening a form. It is the quick route when ten or fifteen people come in at once and you already know their details.
Every press of + Add new users creates a real record, even if you leave it empty. If you press it too many times you end up with records without an email in the list, and they have to be cleaned up.
For larger volumes, the upload is prepared in a file outside the panel and is not launched from these screens.
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: restricting who a challenge reaches. The difference is that you define it, with whatever logic you need.
- It is assigned from the person's record, in the Eligibility Group field.
- It takes several per person: someone can belong to two collectives at once.
- The field only appears in projects configured to use eligibility groups. If you can't see it on the record, your project does not have them enabled.
Eligibility groups are not created from the panel. The Eligibility Groups menu entry leads to the list of people, not to a group editor: to create a new group you have to request it.
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
Someone with the manager role over each group of people, or the approval-based challenges 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 challenges that correspond to their segmentation, and they always receive the ones with no segmentation.
- When someone registers, their row on the expected list is linked to their record. 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 only one of the two rows will be linked when that person registers. The other stays empty for ever and muddies the count.
Can I delete a row from the expected list?
The intended action is to deactivate it, not delete it: that way you keep the trace that this person was expected and did not come in.
I typed in the Client ID column and it wasn't saved.
That is correct: that column is informational and the system fills it in. The only data you save yourself in that table are the email and the status.
Do eligibility groups replace the location?
No, they add to it. If a challenge is segmented by location and by group, the person has to meet both conditions to receive it.
Can I move a lot of people to another group at once?
There is no bulk action for that: the group is changed record by record. If the reassignment is large, it is a change worth requesting rather than doing by hand.
I onboard someone halfway through a journey. What do they receive?
The challenges that are live for their segmentation. If the journey uses dynamic dates, they start from the beginning from their own date; if it uses fixed dates, they join at the point the rest have reached.
Limits and warnings#
- None of these screens validates the data you type. A misspelled email or a code that does not exist are saved all the same; the problem shows up days later, when someone says they can't see anything.
- The records created by the quick onboarding button are born empty. If you leave one half done, it stays in the list as a person without an email.
- Eligibility groups are neither created nor edited from the panel, and the field is only visible in projects prepared for it.
- Segmentation by group is evaluated like all the others: removing someone's group immediately withdraws the associated content from them.
- Onboarding halfway through a campaign does not recover what has expired. Challenges 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.