Who can do what
Two kinds of roles: who can work on an app, and what people can do inside the app you build.
There are two different ideas of a role in AppHandle, and it helps to keep them apart. The first is your account's relationship to an app: whether you own it, edit it, or only use it. The second is what a person is allowed to do inside the app itself, which is something you design. There is also the person you hire to work on the app for you. This guide separates the three.
Working on an app: owner, edit, view
Every app has one owner: the person whose account created it. An app can also be shared with other AppHandle accounts at two levels.
- Owner. The owner can do everything. A few things stay with them alone: inviting people and changing who has access, changing whether the app is public or private, everything about credentials — adding one, replacing its value, changing who may use it, deleting it, and approving a hired person's request to use one — deleting the app, and approving payments.
- Edit. Someone with edit access can open the app in the desk and work on it: asking the builder for changes, publishing a new version, using the app's server-side functions, opening the Data tab, and managing App users. They cannot invite people, change anyone's access, change whether the app is public or private, touch a credential, or delete the app.
- View. Someone with view access can use the published app. They cannot open it in the desk or change it.
These levels apply to the whole app. A person's level does not vary from page to page.
The Data tab shows every record the app has stored, from every user, and it does not say who saved each one. An editor sees the same list you do.
What each level can reach inside the app
What each level can reach follows from that. Editors can run the app's server-side functions. Someone with view access can use the app — functions the owner opened to signed-in users, and the records they save themselves — but not your connected accounts, and never a credential the owner kept to themselves. Visitors who have not signed in reach only the parts the owner opened to everyone; anything needing a signed-in user turns them away.
Inside your app: roles you design
Sign-in tells your app who someone is: their name and their email address. It does not include a role such as administrator or member. If your app needs one, the builder creates it.
Ask in the terms of your situation:
Staff whose email ends with our company domain can add and edit products. Everyone else can only view them.
Only the account owner can see the takings page and delete records.
The app keeps the role as part of its own records and shows or hides parts of itself according to who is signed in. You decide the names, what each role may do, and how someone is placed in a role. The simplest approach is a rule the builder applies, such as a list of administrator email addresses.
Two limits are worth knowing before you plan around roles:
- Inside the app, a person sees the records they saved, and not those saved by anyone else — unless the app has opened that kind of record up, which the builder decides per collection while building it, either for you, your editors and a hired AppHandler, or for everyone who signs in. Ask for the view in those terms: "the teacher sees every submission" is a kind of record the app can show in full, and the builder sets that when it builds the page.
- The app knows the person who is signed in at that moment. It cannot look up other people's accounts or list everyone who has signed in.
You can always see every record in the desk's Data tab, whichever setting applies, though it does not say who saved each one.
If you need more than that, describe the outcome you want and the builder will tell you what is possible for your app before building it.
A hired AppHandler
You can hire an AppHandler to work on the app for you. He opens the app inside AppHandle and works on it there.
He can drive the agent, publish the app, and open the Data tab. He can also see the credentials your app uses: their names, and whether each one is filled in. He is never given a value. He can write code that refers to a credential and test it, and the app's own code still uses the value normally, but it is never placed in his hands.
If the code he writes needs a credential the app does not have yet, the request appears for you in Settings → Secrets to approve or decline. Approving lets the app's functions use it; it does not give him the value. Every write to a credential stays yours: adding, replacing, changing who may use it, and deleting.
Only one person can be in a live session on an app at a time, so two people never work as one. If a session is already open, the desk offers to take it over: that ends the other session and starts a fresh one for you, and the code and the conversation stay. Working as an AppHandler covers the arrangement from the other side.
Where the people are in the desk
Open the app and select Open Session, then the Settings tab. Its sections are App, Publish, Team, App users, Monitoring, Skills, Assets, Handle functions, Checkpoints, MCP tools, Project, Integrations and Secrets. Publish is where an app is put live and where its address and access are set.
The two that decide who is who are Team, for the people who can work on the app, and App users, for the people who use it. Credentials live in Secrets.
Where to go next
Invite people to work on your app covers sending and changing invitations, Who can use a key you store covers credentials, and Choose who can open your app covers the setting that decides who gets in at all.