Identity and sign-in
Sign-in for the apps you publish
Every app you publish on Autessa chooses a hosting mode that decides who can open it: team-only with Autessa sign-in (the default), Public, Access Code, Custom Auth accounts with email, Google or Microsoft sign-in, or personal access links. Each visitor gets their own identity, and row rules can limit each one to their own records.
The problem
What problem does it solve?
A client portal, a job site or a vendor form must let outside people in without making them company members, and without letting one visitor see another’s data.
How it works
- 1
Open Share on the app
Sharing decides which teammates can open and edit the app; the hosting mode decides how end users run the published app.
- 2
Pick a hosting mode
Team-only, Public, Access Code, Custom Auth or Personal access links. Non-default modes get a public URL with your slug.
- 3
Set sign-in methods and length
For Custom Auth, choose any mix of email, Google and Microsoft. Set Keep visitors signed in for from 1 hour to 30 days.
- 4
Scope rows per visitor
Use $CURRENT_CUSTOMAPP_USER_ID, $CURRENT_CUSTOMAPP_ACCESS_LINK_ID or $CURRENT_CUSTOMAPP_USER.region in row rules, so each visitor sees only their own rows.
Every option
Sign-in for the apps you publish: settings and options
| Setting | What it does |
|---|---|
| Team only (default) | Autessa sign-in; each person uses their own access. |
| Public | Anyone with the link. |
| Access Code | A shared code. Default sign-in length 8 hours. |
| Custom Auth | App accounts kept in a table Autessa creates for the app, with a themeable sign-in page. Default 24 hours. |
| Personal access links | A private link per person, no password. Default 24 hours. |
| Keep visitors signed in for | 1 hour to 30 days, per app. |
Permissions
Who can do what?
| Who | What they can do |
|---|---|
| App Admins | Choose the hosting mode and save the app’s permissions. |
| Visitors | Run the app within its permissions and within what the person who saved them can reach. |
| Visitors (rows) | Never change the columns on their own user row, so they cannot widen what they see. |
What to know
- Custom Auth and access-link identities never match each other, so switching an app between modes cannot expose one person’s rows to another.
- Rules that match a visitor’s email apply only once that email is verified.
Connections
How Sign-in for the apps you publish connects to the rest of Autessa
Reports, policies and security questionnaires are on the Autessa Trust Center.
FAQ
Sign-in for the apps you publish: questions
Can people outside my company use an Autessa app?
Yes. Publish it with Public, Access Code, Custom Auth or Personal access links hosting. Visitors do not become company members.
Can app visitors sign in with Google or Microsoft?
Yes. Custom Auth apps can offer email, Google and Microsoft sign-in in any combination.
How do I make sure each visitor sees only their own records?
Add a row rule using $CURRENT_CUSTOMAPP_USER_ID (Custom Auth) or $CURRENT_CUSTOMAPP_ACCESS_LINK_ID (access links). A visitor who cannot fill the placeholder matches no rows.
Get started with Sign-in for the apps you publish
Every app you publish picks a hosting mode, from team-only to Custom Auth accounts with email, Google or Microsoft, and row rules can scope each visitor to their own records.
Reports, policies and questionnaires live on the Autessa Trust Center.
100% customizable, code and all
Make Autessa Security & Compliance fully your own.
Use it out of the box, then change anything. Ask Autobot, Autessa’s AI builder, for a new field, screen, report, workflow or agent and it builds it into your copy of the app. Or open the code and edit it yourself. Nothing is locked: the app, its data and its code are yours.
Start free and make it yours