Skip to main content
Use journey settings when one journey should keep creating work, AI output, and follow-up in the same connected tools by default. 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 use one Figma file for AI import context, when Figma is available in your workspace
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.
1

Open the journey settings panel

Inside the journey editor, open the settings menu and choose Journey settings.
2

Rename the journey if needed

Update the journey name when the current title no longer matches the customer flow you are mapping.
3

Set journey-level defaults

Choose the connected repo, project, database, or design source this journey should use by default.

​
Rename the journey

The first section lets you update the journey name.

​
Journey-level integration defaults

Custory supports per-journey defaults for selected integrations. These defaults help forms and AI start in the right place. They are starting points for new work. Changing a default does not move tasks, pages, or imports that were already created. Current journey-level defaults include:
  • Linear team
  • Jira project
  • Notion database
  • GitHub repository
  • Figma linked source for AI imports, when Figma is connected

​
Why journey-level defaults save time

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 Figma is connected and the journey repeatedly refers back to one relevant design file for AI import context. This is useful for:
  • Redesign work
  • Onboarding or activation flows still evolving in design
  • Product areas where design context is referenced often during review
The settings panel accepts an optional default Figma file key or URL.

​
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 import, 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
Set defaults only for journeys your team uses repeatedly. If the workflow is still changing, leave the defaults flexible.

​
Journey setup mistakes to avoid

If the team still changes repos, projects, or teams often, wait until the pattern is stable.
If a journey points to the wrong repo or project, the team loses trust in the shortcut quickly.
Journey settings should be specific to one journey. Shared configuration belongs at the workspace level.

​
Next step

  • Read Workspaces for the higher-level boundary and ownership model.
  • Read External tasks if you want journey defaults tied to delivery tools.
  • Read AI journey imports if you are setting defaults on an imported journey.