Workers and personas

Most apps behave differently depending on who opens them. A supervisor sees a different case list than a health worker; a form asks a different question of someone in one district than someone in another. App setup → Users and personas is where you describe those people, and it is what lets you preview your app as one of them instead of only as yourself.

There are three things on that screen, and they answer three different questions.

You can make the same changes by chatting with Nova's Solutions Architect. A connected MCP agent can also read and edit worker information, roles, and personas; all three paths use the same checks, so an invalid intermediate never saves.

Worker information

Worker information is the data every worker carries with them, their region, their cadre, their supervisor's name. It isn't case data: it belongs to the person, travels with them into every form, and is the same on every screen they open.

Give each one a name people will recognize and a short key the app uses to refer to it. The key has to begin with a letter or underscore; after that it may use letters, numbers, underscores, and hyphens. Nova also refuses names CommCare has already claimed. The first-character rule matters because this key becomes part of the worker-data XML path that CommCare imports. Nova tells you immediately if a key won't work, rather than waiting until deployment.

If you collapse a worker-information row or look at another row while an edit is unfinished or refused, Nova keeps that draft and its explanation in place. Reopen the row to correct it; switching context never silently resets what you typed.

You can also give a piece of information a fixed list of accepted values. Once you do, any role or persona value you set has to come from that list.

Conditions and calculations can read custom worker information. In an XPath, write its current saved key as #user/<saved-key>. In the condition builder, choose Worker information and select it by name; this stores the stable identity, so changing the saved key updates what Preview and CommCare read without breaking the condition or calculation. Other user field is a separate choice for CommCare-provided or external names and always stays literal, even when its text happens to match a custom key.

While an XPath editor is open, a teammate's saved-key rename appears live when your draft is clean. If you added different text, Nova carries the rename through that addition when it can do so safely. If both edits changed the same text, Nova keeps your draft and asks you to reload the shared version instead of overwriting either edit. Later teammate updates do not dismiss that warning or make the draft saveable; press Escape to reload the latest shared expression before continuing.

Nova will not remove worker information while a saved condition or calculation still reads it. The refusal names the settings to update. Once those references are gone, removal also clears the property's values from every role and persona in the same change.

Nova also shows the information CommCare provides on its own: the project the worker signed into, their name, their locations. You cannot change these, but you can write conditions against them, and each one says plainly whether Nova can show you a real value while you are only previewing. A few cannot be known yet. Keys that CommCare always supplies, including first name, last name, phone number, and the user case's email, remain present with an empty value when Nova has no honest value for them. Target-dependent keys, such as the CommCare project space, remain absent until a deployment supplies one. Nova never invents a value that would make a condition pass in Preview and fail on a real device.

Three of them actually change how CommCare behaves; the rest are simply carried along for your app to read. The screen says which is which.

Saving an answer about the worker

Worker information usually flows one way: you fill it in here, and forms read it. A form can also write back. Set a question's Saves to destination to the worker's own record and pick one of the pieces of worker information you declared above, and the answer is stored on that worker rather than on a case.

That is the right home for anything that describes the person filling in the form instead of the person the form is about, a running count of visits done, a training completed, a supply level they carry. It works on any form, including one that manages no cases at all, and later forms read the value back the same way they read anything else about the worker.

Nova offers only the worker information you declared. CommCare's own fields, the name, the login, the language, the locations, are kept in step with the worker's profile, so an answer saved into one of them would be replaced the next time that worker changed; Nova says so instead of letting you find out later. A question inside a repeating section cannot save here either, because a form writes one worker record and every repetition would be competing for the same slot.

Roles

A role is a job, Community health worker, Supervisor, Data clerk. Give it a name, then fill in the worker information everyone in that job shares. Define it once and every persona holding that role inherits it.

You cannot remove a role while personas still hold it. Nova names them, so you can decide whether to move those people to a different role or remove them first.

Personas

A persona is a specific person: Asha, a health worker in the southern district. Give them a name, pick their role, and change any information that differs from the role's defaults. Inherited values are shown alongside the ones you changed, so it stays obvious which is which.

For each value, Use role value removes the override and returns to inheritance. Remove value does the same when there is no role value to inherit. Clearing the input itself is different: it saves an intentionally blank value, which lets a persona override a role's nonblank default with nothing.

Personas are for designing and testing. They are not accounts, they have no password, and creating one does not create anyone on CommCare. When you are ready to hand out real accounts, Nova makes them from your personas after a publish: see Making workers.

Preview as a persona

From Preview, choose who you are running as. Preview as me runs the app as your own account. Preview as a persona runs it as that person.

This is the whole point of describing them. Previewing as Asha means:

• conditions on worker information see her values, not yours;
• a case list that shows "only my cases" shows hers;
• any case the form creates is owned by her.

Preview always says whose session you are looking at, so the two never blur together. Returning to edit mode also returns the next Preview to Preview as me. If another editor removes the persona you are currently previewing as, Nova stops the running app and asks you to switch back to yourself; it never quietly continues as your account.

Because a persona really owns the cases it creates, removing a persona leaves those cases where they are, owned by someone who no longer exists in your app. This is Nova's policy for design and test actors, not a claim that every CommCare worker-removal path behaves the same way. It avoids quietly deleting or reassigning your real test data. The confirmation counts every retained case the persona owns, including data from case types you have since removed from the app, before it enables removal. Those cases remain available in unfiltered case data views.

What travels to CommCare

When Nova compiles the app, conditions and calculations that read custom worker information use each property's current saved key. The worker running the app must already carry data under those keys for the expressions to see it.

Questions that save to the worker's own record travel as a real CommCare case update against that worker's user case, so the value lands on the device and syncs like any other case change. Renaming a piece of worker information moves the destination with it; nothing in the form needs editing.

Once the app is published to a project space, Nova can make a CommCare mobile worker for each persona. Open Publish, find that project space, and use the Workers list: tick the personas you want, adjust the username Nova suggests, and choose Make workers. Each account carries that persona's worker information and the places it stands in, and each new one comes with a password shown once, right there. Copy them before you close the dialog. Nova keeps no copy, so a password you lose has to be reset on CommCare HQ.

A few things that follow from how CommCare works:

• The username cannot change later. CommCare fixes it when the account is made. Giving a persona a different username makes a second account and leaves the first one alone.
• A username already in use belongs to somebody. Nova refuses rather than writing over it, shows you the account, and takes it over only if you say so for that exact account.
• Removing a persona never deletes the worker. CommCare's own delete also deletes every case that worker owns, so Nova will not do it. The account is reported as left behind, and removing it is yours to do on CommCare HQ.
• Roles are separate. Nova does not create CommCare user roles, and it does not set up your project's custom user-data schema — CommCare offers no way in for either, so both stay on the setup list Nova shows you.
• Worker information marked required has to have a value. CommCare will not save a worker without one, so a persona missing one is named before anything is created. Publishing still works: publishing creates no workers.

One thing worth knowing about the devices themselves: CommCare merges worker data into a device on each sync and never clears it. If you remove a piece of worker information after clearing every app reference to it, it stays on a device that has already downloaded it until that device does a full resync. Nova does not simulate that in preview, it is a property of the platform, not of your app.