# Add a user and control what they can see

Create a new user account, understand how group and direct permissions combine, and grant exactly the document access the person needs — starting read-only and widening from there.

Product: content-central · Versions: 7.x · Audience: system-administrator · Time: About 15 minutes · Last verified: 2026-08-30

Canonical: https://help.ademero.com/content-central/administration/add-a-user

**At the end of this guide you'll have a new user who can log in and see exactly the documents they should — nothing more — and you'll know why "just make them like Bob" is the one shortcut to avoid.**

## How access works — read this first

A user's effective access to a document type is the **combination** of every source that grants it:

| Source | Applies to |
| --- | --- |
| **Direct user permissions** | That one user, on that document type |
| **Group permissions** | Every member of the group, on that document type |
| **Creator permissions** | Whoever created each individual document |

If **any** source grants a permission, the user has it. There is **no deny** — you cannot subtract access with another group or a direct setting. A user in ten groups where one allows Delete can delete.

> **IMPORTANT:** One generous group grants access everywhere it's used. Before adding a user to a group, know what that group can touch.

Also good to know: **Search**, **View**, and **Browse** are three separate grants. Search lets a user find documents, View lets them open what they find, and Browse lets them see documents in the folder view. Granting only one of the three is a common cause of "I can't find my document" calls.

## Decide before you click — four questions

Most user-setup pain comes from granting first and thinking later. Answer these with the person's manager before touching the admin pages:

1. **Which catalogs and document types does their job actually touch?** That list — not "whatever Bob has" — is the access they need. Think in roles: if a role exists as a group, membership *is* the setup; if it doesn't, creating the group now pays off the third time someone joins that team.

2. **Do they approve documents, or just submit them?** Being able to *see* invoices and being an *approver* of invoices are different decisions with different owners. Approval membership changes real business routing — it's a process-owner call, not a permissions default.

3. **Should anything notify them?** Notification recipients and workflow targeting are business roles, not access — add them only when the person genuinely takes on that duty.

4. **Are there restrictions?** If your system limits document access by a field value (departments, regions, client codes), the new user needs their own correct values from day one — and any field-level rules in approval queues are set per member, deliberately.

Direct user grants are the exceptions list. Reach for them when the need is genuinely one-person-one-doctype — and expect [offboarding](/content-central/administration/offboard-a-user) to have to find every one of them later.

> **NOTE:** Setting someone up to match an existing employee? There's a dedicated recipe for doing that correctly: [Set up a new user like an existing user](/content-central/administration/set-up-a-user-like-an-existing-user).

## Step 1 — Create the account

1. Go to **Administration > Users** and click **New User**.

2. Fill in **Username**, **Password**, **First Name**, **Last Name**, and **Email**, then click **Create**. Leave **Guest account** and **Disabled** unchecked for a normal employee.

*[Screenshot: The New User dialog showing the Username, Password, First Name, Last Name, and Email fields with the Create button]*

**What you should see:** the new user's detail page, with tabs for **Details**, **Groups**, **Admin Permissions**, and **DocType Permissions**.

> **NOTE:** A new user starts with nothing — no groups, no document access, and every admin feature off. That's by design: everything they can do from here is something you granted on purpose.

## Step 2 — Add them to groups

Prefer groups over direct user permissions. A group named for a role ("Accounting", "HR Managers") documents *why* someone has access, and updating the group updates everyone in it. Save direct user permissions for genuine one-person exceptions.

1. On the user's **Groups** tab, click **Add to Group** and use the **Select Group** search to add each role the person holds.

2. Need a new group? Create it at **Administration > Groups** with **New Group** (just a **Name** and **Description**), then add members with **Add Member**.

> **NOTE:** The group page itself doesn't set document permissions — those live on each document type, covered next.

> **WARNING:** Membership in the built-in **Administrators** group bypasses all permission checks and grants full system access. Add someone only if they should administer the entire system.

## Step 3 — Grant document-type permissions

Documents live in document types, organized under catalogs. Access is granted per document type:

1. Go to **Administration > Catalogs & Document Types**, find the document type, and choose **Permissions** from its actions menu.

2. On the **Group Permissions** tab, click **Add Group** and add the user's group (or use **User Permissions > Add User** for a one-person exception).
   
   **What you should see:** a new row with every permission off. Nothing is granted until you turn it on.

3. Click the row's edit control to open the **Edit Permissions** dialog and enable what the role needs — start with **Allow Document Searching**, **Allow Document Viewing**, and **Allow Document Browsing** for read-only access.

*[Screenshot: The Document Type Permissions page showing the Group Permissions tab with the Search, View, and Browse columns enabled for one group]*

> **NOTE:** Some grants auto-include their prerequisites — for example, enabling Edit, Delete, Add, Share, or Download also grants View. You can't create a user who can edit a document they can't open.

> **NOTE:** The **Creator Permissions** tab holds one permanent **Document Creator** row. It applies to whoever created each individual document — useful for "you can always see what you filed," but remember it's one more source in the merge.

Removing a group or user row deletes it entirely — they lose all access to that document type unless another group still grants it.

## Step 4 — Approval processes are a separate decision

Document-type permissions control what a user can *see and do*. Whether documents are *routed to them for approval* is configured separately, per process:

1. From the document type's actions menu on **Catalogs & Document Types**, open **Approval Processes** and select a process.

2. In the **Members** section, use **Add Member** (**Add User**, **Add Group**, or **Add Created-By User**) only if this person should approve documents. Check the **Start** column to set where new assignments begin.

3. Notification recipients are the process members themselves — the **Options** section's **Notify member of new arrivals** controls whether members are alerted when documents reach them.

> **WARNING:** If a process is set to automatically start on all captured content of its document type, anyone you add as a member starts receiving routed documents immediately — no one has to assign them anything.

## "Make them like Bob" — copy with care

Mirroring an existing employee touches security groups, direct permissions, approval-process membership, field rules, and notification settings all at once. The dangerous part is approval routing: copying Bob's setup can **silently add the new person as an approver**, and documents start waiting on someone who doesn't know they're in the chain.

> **IMPORTANT:** Instead of copying wholesale, add the new user to Bob's *groups*, then review each approval process on the document types those groups can reach and decide deliberately whether the new person belongs in the routing.

## Step 5 — Test with least privilege

Grant read-only first (**Search**, **View**, **Browse**), then verify as the user before widening access:

- [ ] They can log in.
- [ ] They can find a document by searching, open it, and see it when browsing folders.
- [ ] They **cannot** see document types outside their role.
- [ ] They are not receiving approval notifications unless you added them to a process on purpose.

Once read-only checks out, return to **Step 3** and enable the additional grants the role needs (Add, Edit, Download, and so on). Adding to a working baseline beats debugging an over-grant later — remember, there's no deny to fall back on.

## Still stuck?

If the new user still can't see what they should after the Step 5 checks pass everywhere else, contact support with: the username, the document type name, every group the user belongs to, which of the three grants (Search / View / Browse) fails, and your Content Central version.

## What's next

- [Offboard a user](https://help.ademero.com/content-central/administration/offboard-a-user)
- [I can't find my document](https://help.ademero.com/content-central/search-and-find/cant-find-a-document)