Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.usecustory.com/llms.txt

Use this file to discover all available pages before exploring further.

For founder-led and product-led teams, team setup matters more than most people expect. If too many people can edit too early, the journey becomes inconsistent. If too few people can contribute, the map becomes stale and biased toward one function. The goal is not maximum access. The goal is the right access.

​
Who to invite first

Start with the people who already hold customer context or make decisions from it. Good early members:
  • Founder or product lead
  • Support or customer success lead
  • Product engineer or engineering lead
  • Designer or researcher if they actively shape the flow
For most smaller teams, 2 to 5 editors is a strong starting point.

​
Roles in practice

Custory uses three core human roles.

​
Owner

Owners manage the workspace itself. Owners typically handle:
  • Workspace settings
  • Billing and usage settings
  • Member and invitation management
  • Role changes
  • Integration management
  • Destructive workspace actions
Give this role to a very small number of people.

​
Editor

Editors maintain the working system. Editors typically:
  • Create and edit journeys
  • Add and update items
  • Manage journey context
  • Build or maintain automations
  • Work with integrations relevant to daily operations
This is the role most cross-functional operators should have.

​
Viewer

Viewers follow the work without changing the source of truth. Viewers are useful for:
  • Advisors
  • Exec stakeholders
  • Sales or GTM teammates who need visibility
  • Teammates who should read context but not reshape it
Use Viewer by default when someone mainly needs visibility.

​
Invite team members

Open Workspace settings -> Members and invite teammates by email. When you send an invitation, you choose the role up front:
  • Editor
  • Viewer
That matters because role choice affects both editing power and, on some plans, seat usage. If the same person may need edit access later, start them as a viewer until they are actually part of the operating workflow.

​
Pending invitations

Invitations stay visible in the members table while they are pending. Use that state to answer questions like:
  • Has this person already been invited?
  • Are we waiting on acceptance?
  • Should we cancel and resend instead of inviting twice?
Owners can cancel a pending invitation if it was sent to the wrong person or the wrong role.

​
Join requests

Custory also supports join-request flows when someone discovers an existing workspace and needs access. Owners can review pending join requests in Workspace settings -> Members and then:
  • Approve the request
  • Reject the request
This is especially useful for growing teams where new hires or adjacent teammates already share the company domain but should not be added silently.

​
Change roles carefully

Role changes should follow actual responsibility, not convenience. Promote a viewer to editor when they:
  • Regularly update the journey
  • Own follow-up work from the journey
  • Need to maintain context, not just read it
Move an editor back to viewer when they:
  • No longer maintain the operating map
  • Only need visibility
  • Are creating unnecessary editing noise
For small teams, editors should be accountable contributors, not a catch-all default.

​
Remove members

Remove someone when they should no longer have access to the workspace. Common cases:
  • They changed teams
  • They no longer work on that product area
  • Temporary access is finished
Removing someone is usually better than leaving stale permissions in place “just in case.”

​
How to structure the first team

For most startups, this split works well:
  • 1 to 2 owners
  • 2 to 5 editors
  • Everyone else as viewers
That keeps the workspace collaborative without turning every page into an uncontrolled editing surface.

​
Avoid these setup mistakes

​
Making everyone an editor

This feels inclusive, but it usually lowers trust in the map.

​
Keeping billing owners and workflow owners separate without coordination

If one person controls billing and another controls operations, make sure both understand seat and usage implications.

​
Using Viewer for people who actually own updates

If someone is responsible for keeping part of the journey current, they should not have to work through someone else.

​
Letting stale invitations pile up

Pending invites create confusion. Cancel the ones you no longer need. Use this default:
  • If someone needs to shape the map, make them an editor.
  • If someone only needs to understand the map, make them a viewer.
  • If someone manages workspace structure, billing, or permissions, make them an owner.