Skip to main content
Once your site is set up with page types and blocks, it’s time to hand it off to content editors. This guide shows you how to invite collaborators, manage permissions, and ensure a smooth handoff.

​
Watch the workflow

Watch the workflow in Primo. Download video · Download captions
  1. Open More options, then Collaborators.
  2. Enter the collaborator email address.
  3. Choose Content Editor to allow content changes.
  4. Generate an invitation link to share with the editor.

​
Before you invite an editor

You need developer access to a deployed site. Configure its page types, available blocks, and fields, then create an example page for each workflow. Collaborator controls are hidden in local development mode (primo dev). Connect a reachable site domain before generating invitation links. For email invitations, enable SMTP in the PocketBase dashboard at /_/ and configure a sender address. You can generate a link without SMTP.

​
Invite a collaborator

1

Open collaborators

In the site toolbar, open More options → Collaborators.
2

Enter an email and choose a role

Enter the collaborator’s email address. Choose Content Editor for content work or Developer for code and structure changes. Check the role before submitting: the form initially selects Developer.
3

Generate a link or send an email

Choose Generate link, then copy the displayed link and share it with the intended person. A new user follows it to create a password; an existing user signs in with their existing account.If SMTP is enabled, Send invite sends the invitation email. The form has no custom-message field; include handoff instructions when you share the link or follow up separately.
4

Verify access

Ask the collaborator to sign in, open the example page, edit content, save, and preview it. For a Content Editor, verify that code and page type controls are unavailable.
Treat a password-creation link as private. Share it only with the invited person. Developer access allows code and structural changes, so grant it only to people who need those controls.

​
Roles and permissions

Publication applies to the site. Primo does not offer a per-page unpublish switch or a site-analytics dashboard as part of these roles. Hosting-provider access is managed separately from Primo roles. Site-level assignments grant access to that site. Users with a server role can access sites across the instance; they appear separately in the collaborator list and cannot be removed through a site’s remove action. A PocketBase superuser is a separate administrative account with access to the backend.

​
Manage access

Open More options → Collaborators to view server members and site collaborators. Use the remove action on a site collaborator and confirm removal. Their content remains in the site. The current collaborator list displays roles without an editable role dropdown. To change a site assignment through this interface, remove it and add the existing user again with the intended role. Their account and password remain in place. Server-role access must be changed by a server administrator.

​
Hand off the site

1

Prepare examples

Create representative pages with useful content, clear field labels, and a focused selection of blocks. Explain which content is shared across pages.
2

Walk through editing

Show the editor how to create a page, edit inline, use the content form, save, and publish. Share Using the editor.
3

Agree on publication

Decide who reviews changes before the site is published. This is a team process; page metadata such as a Date field does not enforce approval or scheduling.
4

Keep backups

Configure PocketBase backups and save your local work before pulling from the hosted server. CLI revision checks prevent stale pushes from silently replacing editor changes.

​
Troubleshooting

Without SMTP, use Generate link. If SMTP is enabled, check the sender settings, PocketBase server logs, recipient address, and spam folder. Test delivery from the PocketBase settings before inviting more users.
Check both the server-member list and site assignments. The user may already have access through a server role or an earlier invitation. Give them the site’s admin URL to sign in.
Enable the block in the page type’s available-block list. If the page type has no available blocks, editors can edit existing body content but cannot add new sections.
Update the block as a developer or expose a specific Select or Toggle field. Avoid granting Developer access just to change one content option.

​
Next steps

Set up page types for editors

Choose useful fields and editing guardrails.

Using the editor

Share the editing workflow with your team.