space.vars.productName are existing **NetSuite entities** — employees, customers, vendors, partners, contacts — that you provision for portal access. The Give Access flow links the entity to a role on the active subsidiary.
## When to use this
Use Give User Access whenever a NetSuite entity needs to log in to a portal for the first time. To **change** an existing user's role or branding, use the **Edit** action on their row in [User Management](/client-admin-guide/managing-users.md) instead.
## Before you start
* The user must already exist as a NetSuite entity. This flow doesn't create new NetSuite records.
* The role you want to assign must exist on this subsidiary. If it doesn't, create it first via [Roles & Permissions](/client-admin-guide/managing-users/roles-and-permissions.md).
* The subsidiary at the top of the dialog is the one in the top-bar selector — switch subsidiaries before opening the dialog if needed.
## Step by step
{% stepper %}
{% step %}
### Open the Give Access dialog
Go to **User Management** and click **Give User Access** in the top-right. The dialog title reads **Give Access** with the active subsidiary name shown next to it.
{% endstep %}
{% step %}
### Choose the entity type
Pick one of:
* **Employee**
* **Individual Customer**
* **Company Contact**
* **Vendor**
* **Partner**
The Search field stays disabled until you choose a type.
{% endstep %}
{% step %}
### Find the entity in NetSuite
Start typing in **Search User** — the placeholder adapts (e.g. *Search employee…*). Results appear in a five-column list: **ID / Company / Name / Email / Type**. Only entities that don't already have access on this subsidiary are listed; if nothing matches, you'll see *No results found*.
Click the entity to select it.
{% endstep %}
{% step %}
### Pick a role
The **Select Role** dropdown appears once an entity is selected. The list is filtered to roles for that entity type — for an Employee you'll see Employee roles, for a Customer you'll see Customer or Customer Contact roles. Each role is linked to a workflow that defines the portal experience.
If the role you expect isn't in the list, check that it exists for this entity type via the **Modify Role** button on the User Management page.
{% endstep %}
{% step %}
### Set a password (some entity types only)
Password fields appear only for entity types that need portal credentials:
* Individual Customer (CustJob)
* Company Contact
* Partner
* Partner Contact
Employees and Vendors sign in with their existing NetSuite SSO and don't see password fields.
When the fields are shown, the password must be:
* at least 8 characters
* contain at least one lowercase letter
* contain at least one number
Re-enter the same value in **Confirm Password**.
{% hint style="warning" %}
If the system later returns `PASSWORD_REQUIRED`, the password fields appear automatically with an inline prompt — fill them in and resubmit.
{% endhint %}
{% endstep %}
{% step %}
### Grant access
Click **Give Access**. You'll see *Setting up user account and granting access…* while the user is registered in NetSuite (and SSO, if applicable). On success, a green banner reads *Access has been granted to {email}* and the new user appears in the table.
Click **Cancel** at any point to discard and close the dialog.
{% endstep %}
{% endstepper %}
## Editing or revoking access later
Both actions live on the row's **…** menu in the User Management table.
**Edit** opens the Edit User dialog with these fields:
| Field | Notes |
| -------------------- | ------------------------------------------------------------------------------------------- |
| **Email** | Editable. |
| **Entity Type** | Read-only — fixed at creation. |
| **Role** | Filtered by entity type; the user's current role is pre-selected. |
| **Password** | Optional — leave blank to keep the existing password. Same complexity rules as Give Access. |
| **Confirm Password** | Required only if Password is filled in. |
| **Logo** | User-specific logo override. Leave blank to use global branding. |
| **Theme** | User-specific theme. Leave blank to use the default. |
| **Default Catalog** | Catalog the user sees by default. Leave blank to use the global default. |
**Revoke Access** removes the user's ability to log in but keeps their record and history. Re-grant later with this same flow if needed.
{% hint style="info" %}
Revoking is preferred over deleting — history stays intact and you can re-grant access later.
{% endhint %}
## What success looks like
* The new user appears in the User Management table on the active subsidiary.
* They can log in to their portal and see the role's workflow.
## Common issues
| If you see… | Try… |
| ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| The entity isn't in Search User | They probably already have access on this subsidiary. Use the table (filter by Entity Type) to find them. |
| Search User is disabled | Pick an entity type first — it stays disabled until then. |
| The role dropdown doesn't appear | Select an entity in Search User first. |
| *Password must be at least 8 characters* | Update the password to meet all three rules. |
| *Passwords don't match* | Re-enter both fields identically. |
| `PASSWORD_REQUIRED` returned after clicking Give Access | The entity needed a password but none was provided. The fields appear automatically — fill them in and try again. |
| The user logs in but sees the wrong portal | Wrong role assigned. Edit the user's row and change the role. |
| The user can't log in | Confirm they appear in the table on the right subsidiary. Re-run Give Access if their record is missing. |
## Related
| Roles & Permissions | Create the roles you'll assign here. | /pages/90JTHrYiNFq2sGVsSqGI |
| How Access Works | The four layers — subsidiary, workflow, module, component. | /pages/uS8wD6HP0bikYAq7vn2v |
| PIN Override | Set up PIN-based authorization for sensitive actions. | /pages/ZB1p1C3xoZi8Tr9w4b1S |