> For the complete documentation index, see [llms.txt](https://docs.phocassoftware.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.phocassoftware.com/administration/users/add-update-user/user-account-page.md).
# User account page
You access a user’s account page (sometimes called a *user maintenance form*) when you add and update a user account. The account opens in a window over the **Users** page.
This page contains several user details, permissions and other settings, organized into tabs. Depending on your own profile, you might not see all the tabs.
Click **Administration** > **Users**, locate the user and click their name to open their account page.
On the **User**, **Profile**, and **CRM Restrictions** tabs, click **Edit** to make changes, then click **Apply** to apply them or **Revert** to discard them. On the other tabs, any changes you make apply immediately. When you finish, click the **X** to close the window and return to the **Users** page.
{% hint style="warning" %}
If you make any changes to any tabs on this page, ensure you click **Apply** to apply those changes. If you click the **X** or move to a different tab first, your changes are not saved.
{% endhint %}
***
## User tab
The **User** tab displays when you are adding a new user account (other tabs display afterward) and it is the default tab that displays when you open an existing user account. This tab has the following settings:
* **Username (mandatory)**: This is the name the user will use to sign in to Phocas. This usually matches the user's network sign-in name.
* **LDAP Authenticated?**: This setting is only available on LDAP configured implementations. It indicates which authentication method is been used. If the checkbox is selected, the user is authenticated against the LDAP server. If the checkbox is not selected, the user is authenticated against Phocas. If the user is being added from a source other than Active Directory, an additional **Password** setting is available. See [Configuration > LDAP](/administration/configuration.md#ldap).
* **SAML Authenticated?**: This setting is only available if the Single sign-on (SSO) feature is turned on for your Phocas site, in which case the checkbox is selected by default.
* **Windows or SQL user name**: This setting is only required for older desktop versions of Phocas.
* **Email**\*: This is the user's email address. Users need a valid email address to receive subscriptions. New users on the current version of Phocas will be asked to enter an email address the first time they sign in, unless one has already been entered here.
* **Display Name (mandatory)**\*: This is the name that displays on the **User** menu.
* **Phone** and **Cell**\*: These are the user’s telephone numbers.
* **Language**\*: This is the user’s language, which affects the user interface (UI), number formatting, and date formatting in Phocas. See the [Account settings](/basics/getting-started/account-settings.md#change-the-language) page for general information about the language settings in Phocas and their impacts.
* **Timezone**\*: This is the user’s timezone. The list includes all IANA timezones.
* **Home**: This is the user’s default homepage. You can either leave this blank to present the user with a homepage listing the databases, dashboards and favorites to which they have access, or select a dashboard (to which they have access) as their default home screen.
* **Group**, **Territory** and **Team**: These settings are only available if you have the **Administration** > **Users: All Users** permission. These items make [bulk updates](/administration/users.md#update-users-in-bulk) easier and allow filtering in some areas of Phocas.
* **Password**: This setting determines if the user receives sign-in details by email.
* **Auto-generate password**: If selected, this automatically creates a password that conforms to your site's [password policy](/administration/configuration.md#password-policy) (as long as your site uses the default Phocas authentication), which is always used in conjunction with the **Email details to user** setting below. See Manage passwords.
* **Force password change**: If selected, when the user first signs in, the system forces them to enter a new password.
* **Email details to user**: This is only available if the [SMTP](/administration/configuration.md#configure-the-smtp) details are configured and the user has an email address. If selected, it sends the URL, username and password to the user in an email.
* **License**: This is the user’s Phocas [license type](/basics/getting-started/user-permissions-and-licenses.md) (Full or Viewer) and access to the CRM, Rebates, and Sales Insights modules (if applicable).
CRM license
The ability to assign a CRM license to someone depends on the number of licenses that are available for your Phocas site.
To assign the license to the user, select **Yes** from the **CRM** dropdown list and click **Apply**. While in the user's account page, proceed to assign the CRM permissions on the **Profile** tab.
You can also assign a license to multiple users using the [bulk update tool](/administration/users.md#update-users-in-bulk) or [License view](/administration/administration.md#users-licenceview) on the Users page.
Rebates license
The ability to assign a [Rebates ](https://docs.phocassoftware.com/rebates/)license to a user depends on the number of licenses that are available for your Phocas site. You can assign the license in three ways.
To assign the license to the user, select **Yes** from the **Rebates** dropdown list and click **Apply**. While in the user's account page, proceed to assign the **Rebates** user permission on the **Profile** tab.
You can also assign a license to multiple users using the [bulk update tool](/administration/users.md#update-users-in-bulk) or [License view](/administration/administration.md#users-licenceview) on the Users page.
Sales Insights license
The ability to assign a [Sales Insights](https://docs.phocassoftware.com/sales-insights/) license to someone depends on the number of licenses that are available for your Phocas site.
To assign the license to the user, select **Yes** from the **Sales Insights** dropdown list and click **Apply**.
You can also assign a license to multiple users using the [bulk update tool](/administration/users.md#update-users-in-bulk) or [License view](/administration/administration.md#users-licenceview) on the Users page.
* **Permissions**: These are high-level, site-wide settings applicable to the user.
* **General** > **Account Locked**: This setting controls whether the user’s account is locked.
* **Folders**: These are the [folders](/basics/getting-started/sharing-and-folders.md) that contain the favorites and dashboards the user can access. You can manage these folders in the **Administration** > **Folders** page.
* **Custom Actions**: These are special actions the user can access from the Analytics grid, relevant to the CRM and Rebates modules.
* **Template User**: This setting is only available if the Single sign-on (SSO) feature is turned on for your Phocas site. See Create a user template.
The **Impersonate** and **Reset password** buttons are in the bottom-left corner of the **User** tab.
{% hint style="info" %}
\*Users can change these settings for themselves via their [account settings.](/basics/getting-started/account-settings.md)
{% endhint %}
***
## Profile tab
The **Profile** tab controls what a user can do in Phocas from a functionality perspective. On this tab, you can:
* View the user's permissions if they have an organization profile. You can't edit these permissions here because multiple users can share them.
* Edit the user's permissions if they have a user-specific profile.
* Assign a different organization profile.
* Open the organization profile page, where you can edit the profile name and permissions.
{% hint style="info" %}
If the user has a **Viewer** license (set on the **User** tab), these settings are unavailable.\
If you leave the profile blank (don't assign a profile), the user has no functionality in Phocas. They can view favorites that are in the folders listed on the **User** tab and drill down on the resulting data, but they can't create new favorites or change modes within the existing ones.
{% endhint %}
See the Profiles page to learn more about the different types of profiles and how to assign them to user accounts.
***
## Databases tab
The **Databases** tab displays a list of the Phocas databases. This is where you control the data the user can access in Phocas. Even if a user has permission to do something in Phocas, such as view a favorite or dashboard, if that user does not have access to the underlying data, no data will display. Changes on this tab save automatically. See Manage user database access and restrictions.
***
## CRM Restrictions
This tab becomes available when the user has a CRM license.
Rules-based CRM user restrictions determine what CRM entities (accounts, contacts, leads, and activities) a CRM user can view or edit.
While you can assign users to teams, groups, and territories to help you with user management, these settings are also used in CRM restrictions to determine what CRM entities each user can view and edit. If you have connected with [Microsoft 365 Outlook calendar](/crm/activities/microsoft-365-outlook-calendar-integration.md), these rules also affect what you can see in your activities calendar.
To change the restrictions, click **Edit**, update the rules, then click **Apply** (or **Revert** to discard your changes).
The basic principles of the CRM restrictions are:
* You can always view and edit the entities you *own*. In the following image, you can see the default rule is **Owner Equal To User**, which means that the user (Fiona) is restricted from viewing and editing all CRM entities except for those she owns.
* If you have edit access to an account (or lead), you can edit the entities associated with that account. For example, if your restrictions allow you to edit an account (the parent), you can also edit that account's activities and contacts, and even the contact's activities (the children).
* If you have view access to an account, you can view its entities and meetings (activities).
* Campaigns can be viewed by all users, regardless of restrictions.
* You can view and/or edit other CRM entities if you are linked to the owner of those entities via a restriction rule (as explained in the next section).
* You can view meetings (activities) created against an account in your calendar. If you have , you can also view any .
### Add restrictions
You enable users to view and edit more CRM entities (not just the ones they own) by adding restriction *rules* that link them to those entities. There are two models for adding restriction rules.
#### **Use single values (static)**
Add specific users, groups, territories, and/or teams to a restriction rule, one at a time.
This model is suitable for small organizations that typically have a flat hierarchy or only a few users because:
* When circumstances change, you need to update the restriction rule for each user manually.
* It can be difficult to understand who can access what, as the **Users** page only lists each user’s group, territory, and team, not any others to which they have been linked via a restriction rule. You need to go into each user’s CRM Restrictions tab for such details.
Example: Allow a user to view the CRM entities owned by another user
Suppose you want Fiona to be able to view the CRM entities owned by her colleague Bill.
1. Open the user's account page (Fiona), click the **CRM Restrictions** tab, and click **Edit**.
2. In the **View** section, click **Add**. A new row is added with the default rule of **Owner's team is one of User's Team**.
3. Change **Owner's Team** to **Owner**.
4. Start typing the other user’s name (Bill) into the box and select the name in the list that displays.
5. Click **Apply**. Fiona can now view Bill’s CRM entities along with her own.
This is a very basic example; it would be more common to add additional criteria such as territory, team, and so on.
Example: Set a range of CRM view and edit restrictions for a user
Suppose you want Fiona to be able to view and edit everything within her own team and territory. You also want her to be able to view entities within the neighboring territory (US Central East) but not edit anything relating to that territory.
In Fiona’s user account, on the **User** tab, you can see that she belongs to the US Central North territory and the Sales team. She also belongs to the Electrical group but you do not want to use that group as the basis for any restrictions.
Click the **CRM Restrictions** tab, and click **Edit**.
In the **View** section, enable Fiona to view the additional CRM entities:
1. Click **Add**. The default rule is **Owner's Team is one of User's Team**. In Fiona's case, this is the Sales team. Leave it as it is.
2. Click **Add** to add another rule and select **Owner's Territory**. By default, **User's Territory** displays in the next box. In Fiona's case, this is the US Central North.
3. Start typing US Central East into the box and select the item in the list that displays.
4. Click **Apply**. Fiona can now view anything that she owns, entities within her own team (Sales), and entities within her own territory (US Central North) and US Central East.
Click **Edit** again. In the **Edit** section, allow Fiona to edit the additional CRM entities:
1. Click **Add**. The default rule is **Owner's Team is one of User's Team**. In Fiona's case, this is the Sales team. Leave it as it is.
2. Click **Add** to add another rule and select **Owner's Territory**. By default, **User's Territory** displays in the next box. In Fiona's case, this is the US Central North.
3. Click **Apply**. Fiona can now edit anything that she owns, and entities within her own team (Sales) and territory (US Central North).
#### **Multiple values (dynamic)**
Use the **Group**, **Territory**, or **Team** settings to define multiple values for CRM restrictions.
On the **User** tab, enter multiple groups, territories, or teams, separated by semicolons.
Then, on the **CRM restrictions** tab, when adding a rule, select either the **…(as semicolon separated values)** option or the item containing the semicolon-separated values. Both options produce the same result.
This model is suitable for larger organizations that likely have a more complicated hierarchy because:
* The *set-and-forget* approach reduces the need to manually update restrictions for each user.
* On the **Users** page, it is easier to see at a glance who can access what, which is handy when you have hundreds of users.
Example: Allow a user to view the CRM entities in two territories
Suppose Bert the sales executive is training new sales executives across the country, therefore, you want to allow him to view the CRM entities in multiple territories. You want to update this access from time to time without having to edit Bert’s restriction rule each time. You also want to have an easy way to see which territories Bert currently has access to view.
1. In Bert’s user account page, click **Edit**. In the **Territory** box, type the additional territories after his own territory, separated by a semicolon and click **Apply**.
2. Click the **CRM Restrictions** tab, then click **Edit**.
3. In the **View** section, add another rule. **Owner's Territory is one of User's Territory** automatically displays. In Bert's case, this is the US Central North.
4. Click the box and select **User’s Territory (as semicolon-separated values)** in the list that displays.
5. Click **Apply**. Bert can now view anything he that he owns and all CRM entities in the territories specified on his user account page.
* Back on the **Users** page, in the **Territory** column, you can see all the territories to which Bert is linked.
* If you change Bert’s territories on the user account page > **User** tab, the changes will automatically be applied to the rule in the **CRM Restriction** tab.
### Remove all restrictions
Removing all restrictions gives the user full access to all the CRM entities. This action is suitable for administrators and users who require a broad level of access, as they typically need to view and edit all CRM entities.
Open the user’s account page, click the **CRM restrictions** tab, click **Edit**, select the **No restriction** checkbox, and click **Apply**.
***
## Favorites tab
The **Favorites** tab displays a list of the favorites to which the user has access, which includes any personal favorites created by the user and the favorites shared with them. You can delete any of these favorites. See Manage favorites.
***
## Dashboards tab
The **Dashboards** tab displays a list of the personal dashboards created by the user, if any. You can delete any of these dashboards. See Manage dashboards.
***
## Usage tab
The **Usage** tab displays activity information for the user. See Monitor user activity.
***
## Query Log tabs
The **Query Logs** tab displays details for each query the user makes. See Monitor user activity.
***
## Other tabs
The user account page contains some additional tabs not typically available to administrators, which are used by Phocas implementation and support consultants. These include **Settings** and **Audit**.
---
# 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.phocassoftware.com/administration/users/add-update-user/user-account-page.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.
