# 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. Product: content-central · Versions: 7.x · Audience: system-administrator · Time: About 30 minutes · Last verified: 2026-09-14 Canonical: https://help.ademero.com/content-central/administration/set-up-a-user-like-an-existing-user **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 > **IMPORTANT:** 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](/content-central/administration/add-a-user) 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. > **NOTE:** 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**). > **NOTE:** 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. > **WARNING:** 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](/content-central/administration/offboard-a-user) 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 ## What's next - [Add a user and control what they can see](https://help.ademero.com/content-central/administration/add-a-user) - [Offboard a user without breaking approvals](https://help.ademero.com/content-central/administration/offboard-a-user)