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.
Before you begin
- Administrative access to Content Central's Administration area
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.
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:
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.
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.
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.
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 to have to find every one of them later.
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.
Step 1 — Create the account
Go to Administration > Users and click New User.
Fill in Username, Password, First Name, Last Name, and Email, then click Create. Leave Guest account and Disabled unchecked for a normal employee.
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.
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.
On the user's Groups tab, click Add to Group and use the Select Group search to add each role the person holds.
Need a new group? Create it at Administration > Groups with New Group (just a Name and Description), then add members with Add Member.
The group page itself doesn't set document permissions — those live on each document type, covered next.
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:
Go to Administration > Catalogs & Document Types, find the document type, and choose Permissions from its actions menu.
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.
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.
The Document Type Permissions page showing the Group Permissions tab with the Search, View, and Browse columns enabled for one group
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.
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:
From the document type's actions menu on Catalogs & Document Types, open Approval Processes and select a process.
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.
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.
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.
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.