Visitor sign-in
Your app’s visitors are not members of your workspace. They are the app’s own people. Two things are kept apart:
- Sign-in says who a visitor is. It comes from the sign-in method you choose: a PhiWebs account or your company’s account.
- Roles say what that visitor may do. They live in the app itself: the
roles and access rules in the app’s
auth.json, and who holds which role in the app’s own people list. A sign-in never brings roles of its own.
Everything on this page is in the studio, under App → Sign-in & people.
Choose a sign-in method
Under Visitor sign-in, pick one:
| Option | What visitors do |
|---|---|
| No sign-in | Nothing. Every visitor is anonymous. |
| PhiWebs account | Sign in with a PhiWebs account. |
| Company account | Sign in with your organisation’s Microsoft Entra account, or another OpenID provider. |
With either sign-in method you can also tick Visitors must sign in before they see any page. Without it, visitors can browse, and signing in unlocks what their roles allow.
Click Save sign-in. The choice is saved into the app’s auth.json, so the
agent and the checks see it too. Publish to put it live.
You need the project open to change the sign-in.
Company account (Microsoft Entra)
Fill in:
- Issuer — for Entra,
https://login.microsoftonline.com/<tenant id>/v2.0. - Client ID — the app registration’s Application (client) ID.
- Audience (optional) — only when your app reads its own API.
In Entra, register the app as a single-page application with your app’s address as its redirect URI. No client secret is needed: visitors sign in with PKCE. App roles you assign in Entra count when they have the same names as your app’s roles.
Give the app roles
Roles are part of the app. If the panel says the app declares no roles yet, ask the agent, for example: “Add an admin role that can change every record, and a staff role that can read bookings.” The agent writes the roles and the access rules into the app.
Who can come in
The people settings belong to the published app, so they appear once you have published. Before that, the panel tells you to publish first.
Under Who can come in, choose:
- Anyone who signs in, with the role … — anyone the sign-in method accepts gets in. Pick the role newcomers get, or No role (member) for a plain signed-in member. This is how a new app starts.
- Only people on the list below — invitation only. Anyone else is turned away after signing in.
Click Save.
The people list
Under People you see everyone on the app’s list, with their e-mail, how they got there (Owner, Invited or Signed up) and whether they have signed in yet.
- Invite — enter an e-mail address, pick a role and click Invite. The person’s roles apply when they sign in with that address. The address must be one their sign-in provider has verified. Inviting adds them to the list; send them the app’s address yourself.
- Change roles — click a role on a person’s row to give it or take it away. A person can hold several roles.
- Remove — takes the person off the list. In an invitation-only app this also ends their session.
A role shown struck through is one the app no longer declares. It grants nothing.
The first admin
When you publish an app whose people list is empty, you are added as its first admin. That is why the list never starts without someone who can manage it.
In the preview
The preview has no people list. There you are signed in as the developer and hold every role the app declares, so you can try every page.
See also
- Access — sign-in, roles and access rules explained
- Publishing your app
- Collaboration — the people who build your apps