> For the complete documentation index, see [llms.txt](https://docs.appfarm.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.appfarm.io/reference/security/permissions.md). # Permissions Permissions define granular access rights to apps, Flows, services, data, environments and functionality within Appfarm Create. Permissions are granted to [roles](/reference/security/roles.md) which are in turn assigned to [users](/reference/security/users.md). You must configure permissions for each new role that you create so that end-users can access and use your apps. ## Filter roles In solutions with many roles, you can choose which role columns the **Permissions** page shows. Click the **Filter roles** button in the header, next to undo and redo, and select the roles to show. Built-in roles are listed first, and you can search by name. Select **Clear selection** to clear the filter. The filter applies to every tab on the page, and the button shows a dot while it's active. The filter is kept for the solution until you close the browser tab. ## Apps Grant access to a given [app](/reference/apps.md). You must assign this permission if you create a new app. ## Services Grant access to a given [service](/reference/services.md). This tab is only shown in solutions that use Services. * If a service is run from a [schedule](/reference/operations/schedules.md), the service account that triggers the schedule must have a role with access to the service. * If a service is run via a call from an external application, the [service account](/reference/security/service-accounts.md) holding the [API key](/reference/security/service-accounts.md#api-keys) must have a role with access to the service. * If a user can run a service from within an app, they need a role with access to the service. ## Flows Grant access to a given [Flow](/reference/flows.md). You must assign this permission if you create a new Flow. Every user and service account that runs the Flow needs a role with access to it, whether the Flow is run from an app, through an [API endpoint](/reference/flows/api-endpoints.md), from an MCP server or on a schedule. For calls with an API key, that is the [service account](/reference/security/service-accounts.md) holding the key. ## Flow Actions Restrict which roles can run individual Flow actions. The tab lists the actions that have **Restrict permissions** selected in their **Action settings**. A role's effective access is the intersection of its Flow and Flow action permissions. A Flow action permission can narrow access to a Flow, never widen it. Actions without **Restrict permissions** are available to every role with access to the Flow. {% hint style="warning" %} **Important** Mark actions that are only used inside their own Flow as **Private Action**. A private action can only be run by Run action in the same Flow. Run flow, API endpoints, schedules and MCP clients can't run it. Don't rely on a Flow action not being used by your app to keep users from running it. A user with access to a Flow can call any of its actions that isn't private. Restrict permissions on actions that only some roles should run. {% endhint %} ## Object classes Select which data operations a role has access to, for each [object class](/reference/data-model/object-classes.md) in your solution. When you create a new object class, only the [built-in roles](/reference/security/roles.md#built-in-roles) have access by default. So you must grant access to the appropriate roles. Additionally, when you add a new role, they have no object class permissions at all, so you must grant the required permissions. These permissions can also be configured when [editing an object class](/reference/data-model/object-classes.md#permissions) in the **Data model**. #### You may define Create, Read, Update, Delete, and Aggregate permissions per Role. Here is how this works. * **Create**: When allowed, a user of the Role is allowed to insert a new entry into the database. I.e. a `Persist` (on a newly created object) is allowed, or `Create Objects` towards a database-connected data source. * **Update**: When allowed, you are allowed to persist updates on an existing object. I.e. you to not need the Update permissions if you only create new data. * *For example: If you run `Create Objects` into a runtime-only datasource, then do `Update Object`, and then a `Persist` - There is no need for Update permissions since the Persist results in an object creation. However, if you do another Update Object afterward, and then another Persist - that is a database update, so an Update permission is required.* * **Read**: Must be enabled to allow reading data from the database (either with Read Object, or when using a Filter on a database-connected data source). * *If you only do a `Create Object`, and a `Persist`, there is no need for Read permissions.* * **Delete**: Must be enabled to allow database deletion. * *If you only do a Delete Objects on a runtime-only data source, there is no need for the Delete permission.* * **Aggregate**: Must be enabled to run aggregations on the object class. Treat it like Read: an aggregation can return whole objects, not only counts and sums, so don't grant Aggregate to roles that must not read the data. The **Conditional** columns let you add [conditional permissions](/reference/security/permissions/conditional-permissions.md) for each operation. {% hint style="success" %} **Best practice** Be restrictive, and don't grant permissions that a role doesn't need. {% endhint %} {% hint style="info" %} Important: Create, Update and Delete permissions are not enforced on runtime data sources. I.e. you may create objects info a "Companies" data source even though you have no "Create" permissions. Permissions are enforced in the layer towars the database. {% endhint %} ## Time Series Select which operations a role has access to (**Create**, **Read** and **Aggregate**) for each time series class in your solution. This tab is shown when time series are enabled for the solution. Conditional permissions don't apply to time series classes, so don't store data that must be separated between tenants in a shared time series class. ## Login Grant access to a given [environment](/reference/configuration/environments.md). For example, you might have a role for testing which only needs access to the Test environment. {% hint style="info" %} **Good to know** The built-in roles do not have access to Test, Staging, or Production. {% endhint %} If you've created a custom role that needs access to Appfarm Create, that can also be granted under **Login**. ## Accounts/Roles Manage permissions for adding, updating, and deleting users, service accounts, and individual roles. This includes assigning and removing roles. If you have functionality in your apps or services for adding, modifying, or deleting users, the appropriate permissions must be granted here. The tab has these sections: * **User and Service Account**: read, create, update and delete users, and read, create and update service accounts. * **Role Management**: create, update and delete roles, and assign or remove users from the Developers and Maintainers roles. * **Assign User to Role** and **Remove User from Role**: one row per custom role. * **Assign Service Account to Role** and **Remove Service Account from Role**: one row per custom role. * **Update User in Role** and **Delete User in Role**: one row per custom role. Needed to update or delete a user who has that role. * **Act as Service Account**: one row per service account. Lets the role run a Flow or Service as that service account, with **Run as Service Account** on the Run Flow or Run Service action node. The service account still needs its own permissions to run the Flow or Service and to read and change its data. Grant it per account, and give each elevated task its own service account. * **Special Owner Permissions**: permissions that apply to every role and user, such as **Update Permissions on any Role** and **Delete any User**. Changes on this tab take effect immediately, without a deploy. {% hint style="info" %} **Good to know** When performing user management operations from inside an app or service, the built-in role privileges are not valid. {% endhint %} ## Advanced Advanced permissions include privileges within Appfarm Create. Typically, you would only use these if you create a custom role which requires access to Appfarm Create. These permissions allow you to tightly control which parts of Appfarm Create that role has access to. For example, to allow access to only one specific app or restrict deploying to Production. This is also where you can grant a role the permission **Update Secret from Service**. This is required when you have a service run by a schedule that fetches an authentication token from an external API and stores that token in a [secret](/reference/security/secrets.md). --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.appfarm.io/reference/security/permissions.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.