# Add users and assign roles
This section covers adding and updating **Users** and providing them with the correct **Roles**.
An important note on Users in Appfarm is that one User (with a unique email as login) may exist only once inside a solution. The built-in User database is shared across environments. Therefore, it is important to provide a User with the correct Roles and restrict access to various environments by Roles.
{% hint style="info" %}
Users and Roles is also covered by a series of videos in the [User handling and permissions module](https://docs.appfarm.io/appcademy/appfarm-fundamentals/user-handling-and-permissions) of the Appcademy Fundamentals learning path.
{% endhint %}
### How Appfarm evaluates a User in the client (Apps)
When logging into the client (`https://YOUR-HOST-NAME`), you meet the login screen (unless you have a direct link to an App with Public Access). Upon login, if authentication succeeds, your User's Roles are evaluated.
First off, Appfarm evaluates if your (user's) Role(s) have access to log in the the Environment you are trying to access. The configuration of login access vs environments is configured from **Permissions > Login**.
If your Role(s) have access to more than 1 App, a splash screen for App selection will be presented. If only 1 App is available to you, you will be redirected to it automatically.
When accessing the App, all App Data is read. But only data of those Object Classes allowed to read for your Role(s), as defined in **Permissions** > **Object Classes**. When using the App, creating, reading, updating or deleting App Data will only be allowed if your Role(s) have those Permissions. In other words, you may have access to read data from an Object Class, but not update it.
When setting up logic in your App, you may access the properties of the logged-in user from the built-in Data Source (found in App Data) called `Current User`. When logging into an App, the `Current User` is *you*.
### Adding Users for access to Create
Users may be manually added from the menu **Users**. Providing a User with one of the built-in roles **Owners**, **Maintainers** or **Developers** will give them access to Create. **Owners** have full access inside Create, being able to add other Owners as well. You may view the settings for access *within Create* from the menu **Permissions** > **Advanced**. If you are to add a User with a custom access to Create, you need to add a Custom Role for this, and adjust the Create access from the Advanced Permissions section.
### Adding Users from your Apps (with access to the client)
Obviously, you could create a Custom Role with access to your Apps, and add these users manually from Create.
However, most solutions need an App with functionality for adding or removing Users.
The built-in User object may not be extended with additional properties. In most cases, you would need to create a `Person` **Object Class**. This Object Class should at least have a property `User` with data type **User**, and may have other properties, such as `Company` or `Department`, or `Privacy policy accepted`. *Note: The built-in User object will soon be possible to enrich with custom properties as well, but for now you need a dedicated Object Class for this purpose*.
Adding a new User to your App, would in the above example, require some UI to Create a new Person. For example, a dialog for entering First Name, Last Name and Login (email). Clicking the SAVE button should create a new User (action node **Create User Account**)
* We have runtime properties on the `Person` object for holding `First Name`, `Last Name` and `Email` temporarily. In our example, these properties should only be saved on the User object. You might save these properties to the `Person` object as well (adding these 3 properties as **Object Class Properties** of the `Person` Object Class)
* These properties are copied down to the User object created using **Data Bindings**
* We assign a Role `App Users` in the **Role Memberships** setting
* **Accept Existing User** is ticked. This means, if the User object is already created (e.g. added manually in Create or added from Dev or Test environments), the User object will just be read and updated with the correct Role (defined by the setting **Add Roles** being ticked).
* **Add to Data Source**: We have a runtime-only Data Source (cardinality One) for the purpose of holding the User object just created (or read, if already existing). We need this for updating the reference Person.User to point towards this User object in the next step.
* Optionally, you may tick the **Send Welcome Mail**. A default welcome mail will be sent to the User. The Welcome Mail content may have overrides defined from the menu **Environment Config** (see [this section](https://docs.appfarm.io/reference/configuration/environments)). Or you could just create your own welcome email using the **Send Email** action node.
Once this action node has succeeded, the User just created exists in the User database with correct permissions.
\
The `Person` object is not yet saved. This Action Node (**Create Object**) creates the Person object, with reference to the User object just created. The next Action Node **Persist** saves the Person object to the database.
### Updating Users from your Apps
Updating Users from your Apps is explained following the same example as above.
Note that updating a User's `Email` property must be done by removing the User object (**Delete User Account**) and creating a new user account using **Create User Account**.
You could reuse your UI for creating a `Person`. *Edit a Person* is typically done from a Table listing all Persons. Before opening the dialog for editing, just read the object in context into the Person (temp) Data Source! And if properties First Name and Last Name are not stored on the Person Object Class, just update these 2 runtime-only properties on the `Person (temp)` Data Source (from `Person (temp).User.First Name`, `Person (temp).User.Last Name`) before opening the dialog as well.
The SAVE button could trigger an action as follows:
Executing this action will update the `First Name` and `Last Name` of the **User**.
{% hint style="warning" %}
**Important to note**\
\
When creating or updating Users and assigning or removing roles, these changes can take a few seconds to be fully synced and available across all resources. These changes are event-based - when a change occurs, all resources which need this new data will update their cache, which can take a few seconds to fully sync and propagate.
This is useful to note in situations where logic based on Current User is performed immediately after updates to the User object, for example:
* A registration flow where a new user registers themselves and then logs in immediately afterwards
* Assigning a new role to a User and then navigating the User to a new app (which has restricted access based on this role) immediately afterwards
In these situations, it is recommended to add pauses to the actions using the [Sleep](https://docs.appfarm.io/library/action-nodes/sleep) action node.
{% endhint %}
### Removing Users from your Apps
Action Node **Delete User Account** allows you to delete a user. But note that doing this from the Development or Test environment, for a User that is using the Production environment, will delete the User permanently, leaving the User unable to access the Production environment. Therefore, a good policy is to disable Delete User globally for Dev and Test environments (defined in the **User Account Manipulation** setting of [Environment Config](https://how.appfarm.works/appfarm-create/reference-guide/environments-config), also explained below).
If you do not want to permanently delete the User, you could instead perform an [Update User Account](https://docs.appfarm.io/library/action-nodes/update-user-account), and remove all permissions. This may be done by applying all roles in the **Remove Roles** setting of the **Update User Account** action node (see screenshot for Update User Account above).
### Enable User Account Manipulation setting in Environment Config
Each environment has a global setting found in **Environment Config** > `ENVIRONMENT`. By default, user manipulation from Apps is only enabled for the Production environment. When testing your functionality for adding or updating Users from either the Develop, Test or Staging environment, you need to tick the checkboxes found in **Environment Config** > `ENVIRONMENT`, as illustrated below.
Setting to allow User Account Manipulation, to be turned ON
### Enable which Role may update or create user accounts
From the menu **Permissions** > **ACCOUNTS AND ROLES**, you need to define which Roles are allowed to Create, Update or Delete User Accounts. This setup applies to user manipulation from the Client only, not from Create.
### Handling Service Accounts
**Service Accounts** are users without a username and password. Service Accounts are added manually from Create - no action node exists for adding them from Apps.
**Service Accounts** are members of one or more **Roles**, similar to Users. They follow the same principles with regard to Permissions. But the normal use case for Service Accounts is that they are member of a dedicated Role, and this Role has access to one or more Services.
See [this section](https://docs.appfarm.io/reference/security/service-accounts) for more info on handling Service Accounts.
