> For the complete documentation index, see [llms.txt](https://docs.heisenware.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.heisenware.com/app-manager/users-and-access.md).

# Users and access

Heisenware gives you granular control over who can access your Apps. Each App can have its own security settings, even when several sit in the same workspace.

{% hint style="info" %}

#### Users vs. members

This article covers the users of your Apps. For managing your members, the people who build and manage your Apps, see [Members](/app-manager/members.md).
{% endhint %}

## Access modes

In the Apps panel, choose from five access options to match your security requirements.

<figure><img src="/files/kopDgXMJC7ogBMlx3ae5" alt=""><figcaption></figcaption></figure>

{% hint style="warning" %}
You can change these settings at any time, but each change instantly affects all active sessions. Frequent changes may confuse your users.
{% endhint %}

### Public access

* **Option**: *Anyone can use the app*
* **Details**: The App is open. Anyone with the URL or QR code can access the interface immediately. No login is required.

### Shared security

* **Option**: *Users must provide a master password*
* **Details**: You must define a master password in the settings.
* **Session**: The browser stores the authentication in local storage. Users re-enter the password only on a different device, in an incognito window, or after clearing their browser data.

### Individual registration

* **Option**: *Users have to sign up*
* **Details**: Heisenware manages user accounts automatically. Users can register with an email/password or their Google account.
* **Session**: Like the master password, the browser keeps the login state in local storage. Users stay logged in until they log out or clear their browser cache.

### Dual authentication

* **Option**: *Users have to sign up and provide a master password*
* **Details**: Combines the previous two methods. Users must have a personal account and know the shared master password to gain entry.

### Private whitelist

* **Option**: *Only previously invited users can log in*
* **Details**: This opens an email invite form. Only the specific email addresses you invite can register and access the App.
* **Programmatic invite:** With the [`users` class](/app-builder/build-backend/functions/utilities/users.md) in the backend, you can also invite users programmatically from another App.

## User management

The Users card in each App gives you a real-time view of who is accessing your software.

{% hint style="info" %}

#### Managing users programmatically

You can also manage users from within an App using the [`users` class](/app-builder/build-backend/functions/utilities/users.md).
{% endhint %}

### Anonymized sessions

For Apps using [Public access](#public-access) or [Shared security](#shared-security), the table shows anonymized strings, IP addresses, and session data so you can track unique device usage.

<figure><img src="/files/Sqjg07SAtcqfcap5jtg1" alt=""><figcaption></figcaption></figure>

### Registered profiles

For Apps using [Individual registration](#individual-registration) or [Dual authentication](#dual-authentication), the table shows names and usernames (email addresses). Heisenware recognizes a user logging in from different devices with the same email as the same person.

<figure><img src="/files/Kt22no4d3HH2AmqGdvbY" alt=""><figcaption></figcaption></figure>

### Deleting users

To remove a user, registered account or anonymous session alike, click the trash icon in the list. Deleting a user removes their record and ends their current session.

{% hint style="info" %}

#### Leveraging user data in logic

Once a user is authenticated, the Backend Builder exposes their information through the `$USER` system variable. Use it to personalize the UI (e.g. "Welcome, \[Name]"), filter database queries so users see only their own data, or log exactly who performed an action in your backend.

For example, if a table stores each row's owner in an `email` field, a `getTableData` function can filter for the logged-in user's own rows:

```yaml
# name
orders
# options
filter: ['email', '=', $USER]
```

{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.heisenware.com/app-manager/users-and-access.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.