Set up a new user like an existing user
There's no copy button for users — here's the ordered recipe that reproduces an existing user's access correctly, and the two places where copying blindly goes wrong.
Before you begin
- Administrator access to Users, Groups, and Catalogs & Document Types
Content Central has no clone-user button — but "make Jordan like Bob" is still a thirty-minute job when you rebuild access in the right order. This is that order, plus the two places where blind copying creates problems instead of access.
The order matters because most of a user's real access flows in through groups, and matching groups first reproduces several per-user defaults automatically. Copy in the wrong order and you'll hand-build things the system would have built for you.
Before you start: read the source user correctly
The user detail page's DocType Permissions tab shows only permissions granted directly to that user. Everything flowing in through their groups does not appear there — so an unchecked box does not mean the user lacks that permission. Bob's true access is his direct grants plus every grant of every group he's in. Read both, or you'll copy a fraction of Bob.
- Open the source user and note their Groups tab — the full list
- Open each of those groups and note their permissions — this is usually most of "Bob"
- Note the source user's own DocType Permissions tab per catalog (the
Catalog:selector), Admin Permissions tab, and Catalogs for Admin tab if present
1. Create the user
Go to Administration > Users, create the new user (username, password, name, email — that's the whole form), and save. The permission tabs appear after the first save — see Add a user and control what they can see for the basics.
2. Match group memberships — the big copy
On the new user's Groups tab, use Add to Group to match the source user's group list exactly.
What you should see: most access is now reproduced — and joining groups also auto-creates the new user's default document types and default search/result settings to the group's standard.
If the source user's personal defaults were hand-tuned after they joined their groups, that drift is invisible and doesn't copy. If it matters, compare their default document types side by side afterward.
3. Copy any direct document-type grants
For each direct row you noted on the source user's DocType Permissions tab, grant the same on the new user — either from their DocType Permissions tab, or from the document type's permissions page (User Permissions > Add User).
Before copying a direct grant, ask why it isn't a group. If three people need the same one-off access, that's a group waiting to be created — direct grants are the exceptions list, and every one is a thing offboarding has to find later.
4. Copy administrative rights
- Admin Permissions tab: match the switches (Users, Groups, Catalogs & Document Types, Workflow, Event Viewer, and the rest) only if the new person truly shares the source user's admin role.
- Catalogs for Admin tab (shown when your system limits catalog admins by membership): match the catalog list.
5. Approval processes — decide, don't copy
The source user may be an approver two ways: via a group (already handled by step 2) or directly — their name added under a process's Members. Direct memberships you must find on each document type's approval processes.
This is the step where blind copying does damage. Adding the new user as an approver changes who can approve real business documents — and adding them alongside the source user on an all-must-approve step means every document now waits on both. Ask the process owner whether the new person approves, replaces, or merely submits. "Like Bob" usually means Bob's access, not Bob's signature.
If the new person is replacing the source user outright — same seat, including whatever is already waiting on them — follow the pending-approvals handoff in Offboard a user without breaking approvals instead of copying memberships here.
6. Notifications and workflow targeting
If the source user is a selected recipient on message templates (the Users list on the template) or targeted by workflow actions, decide whether the new user joins those lists. These are business routing decisions, not permissions — copy them only when the new person genuinely takes on that role.
7. The two settings that hide everything
Everything above adds access — these two are the only settings that remove it, and they're where a copied user "mysteriously can't see anything":
- Limiting-field values (on the user detail page, when your system limits document access by a field): the new user needs their own correct values — a blank or copied-wrong value hides documents no grant can bring back.
- Approval field-edit permissions: per-member field rules inside an approval process combine restrictively with document-type permissions. If the source user had them, set them deliberately for the new member.
8. The personal odds and ends
Quick pass on the user detail page: User Substitution, Approval Queue Options, Theme, and the account switches (guest, disabled, profile/password permissions). Copy what makes sense for the role.
Verify — because there's no report that will
Content Central has no "effective permissions" view, so the only real verification is behaving like the user: sign in as them (or reset their password with them at the keyboard) and test the moments that matter — search a document type they should see, browse a folder they should reach, open the Approval Queue if they approve, and capture a test document if they submit.
Still stuck?
Send support:
- The source username and the new username
- The specific difference ("Bob finds invoices by search, Jordan gets nothing")
- Both users' group lists, and whether the grant in question is direct or via a group
- Whether your system uses limiting-field values — and both users' values for that field