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.

Journey settings help you attach the right connected systems to a specific journey. This is one of the simplest ways to reduce friction for smaller teams, because it keeps task creation and AI work pointed at the right destination by default.

​
What journey settings are for

Use journey settings when one journey should consistently work with one specific external context. Examples:
  • This onboarding journey should create GitHub issues in one repository
  • This support journey should use one Linear team
  • This research journey should point to one Notion database
  • This redesign journey should stay linked to one Figma source
Without journey-level defaults, the team has to keep choosing the same destination repeatedly.

​
Open journey settings

Inside the journey editor, open the settings menu and choose Journey settings. From there, you can manage:
  • Journey name
  • Journey-level integration defaults

​
Rename the journey

The first section lets you update the journey name. Do this when the original title is:
  • Too generic
  • Too internal
  • No longer aligned with the product language
Use names that clearly describe the customer flow, not the internal initiative. Better:
  • New user onboarding
  • Connect Slack
  • Trial to paid
Worse:
  • Growth project
  • Activation v2
  • PLG flow

​
Journey-level integration defaults

Custory supports per-journey defaults for selected integrations. These defaults help forms and AI start in the right place. Current journey-level defaults include:
  • Linear team
  • Jira project
  • Notion database
  • GitHub repository
  • Figma linked source

​
Why this matters

For smaller teams, the real cost is not only data entry. It is context switching. If the same onboarding journey always creates work in the same GitHub repo or Linear team, set that once and stop re-deciding it every time. That improves:
  • Speed
  • Consistency
  • Accuracy
  • AI usefulness

​
Set a default Linear team

Use this when a journey regularly turns into delivery work in one Linear team. This is helpful when:
  • Product and engineering already manage that area in one team
  • Most follow-up work from the journey lands in the same place

​
Set a default Jira project

Use this when a journey regularly creates work in one Jira project. This is helpful for teams that route all customer-journey follow-up into a known implementation backlog.

​
Set a default Notion database

Use this when a journey should create or connect work against one Notion database. This is most useful when research, documentation, or structured planning for that journey lives in Notion.

​
Set a default GitHub repository

Use this when a journey consistently maps to one product or service repository. This is especially helpful when:
  • GitHub issue creation starts from journey context
  • AI assistance should assume one repo first
  • The team wants implementation to stay tightly tied to one product surface

​
Set a default Figma source

Use this when the journey repeatedly refers back to one relevant design file. This is useful for:
  • Redesign work
  • Onboarding or activation flows still evolving in design
  • Product areas where design context is referenced often during review

​
How journey defaults affect daily work

Journey defaults help in workflows such as:
  • Creating follow-up tasks
  • AI-assisted drafting
  • Keeping one journey tied to the right design or delivery context
They do not replace workspace-level integrations. They refine them for one specific journey. Think of it this way:
  • Workspace integrations decide what tools are available
  • Journey settings decide which connected destination is the default for this journey

​
Setup advice for founder-led teams

Only set defaults when the pattern is stable. If the team is still experimenting with where work should land, do not rush to configure every journey. Use defaults where they remove repeated friction, not where they add premature structure. A good starting rule:
  • Set defaults for the 1 or 2 journeys the team uses every week
  • Leave the rest flexible until the workflow settles

​
Common mistakes

​
Setting defaults too early

If the team still changes repos, projects, or teams often, wait until the pattern is stable.

​
Leaving defaults vague or mismatched

If a journey points to the wrong repo or project, the team loses trust in the shortcut quickly.

​
Treating journey settings like workspace settings

Journey settings should be specific to one journey. Shared configuration belongs at the workspace level.