GitHub is where customer-context work often either stays connected to delivery or falls apart. Custory’s GitHub integration is designed to preserve that connection. It keeps the line visible from: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.
- Customer problem
- Journey item
- Delivery task
- Pull request
- Shipped change
What the GitHub integration supports
Custory’s GitHub integration is not only for issue creation. It supports a broader delivery loop:- Repository-aware setup
- Linked GitHub issues
- Pull request visibility
- GitHub-triggered automations
- GitHub PR fetch actions
Connect GitHub at the workspace level
Connect GitHub from Manage Integrations. Once connected, Custory can work from your selected repositories instead of treating GitHub as an abstract issue target. That matters because smaller teams usually do not want to type owner and repo details repeatedly or guess where journey-linked work should land.Repository-aware setup
Custory works with repository context so GitHub-backed workflows can stay grounded in the actual codebase. This shows up in several places:- Journey-level GitHub defaults
- GitHub issue creation from items
- GitHub PR triggers in automations
- GitHub PR fetch actions in automations
Create linked GitHub issues from items
You can create GitHub issues directly from journey items. This is useful when an opportunity or solution needs engineering follow-through and the customer reason should remain attached to the issue. A linked GitHub issue helps preserve:- Why the work exists
- Which item it came from
- Which journey step it affects
Journey defaults for GitHub
Custory supports per-journey GitHub defaults so a journey can remember the repo it most often works with. That reduces routing friction and helps teams keep issue creation consistent. See Journey settings.Pull request visibility
Custory also treats pull requests as useful workflow context. That means delivery progress can stay visible to product and support without forcing everyone to monitor GitHub manually all day. This is especially valuable when the team wants to know:- What is actively under review
- What merged recently
- Which customer-facing changes likely need validation
GitHub in automations
GitHub supports automation in two main ways.GitHub-triggered automations
Use GitHub PR events as triggers:- PR opened
- PR merged
- A GitHub integration
- At least one repository
- Base branches
- Notify the team when a customer-facing fix is under review
- Refresh the journey when a PR merges
- Prompt product validation after delivery activity
GitHub PR fetch actions
Automations can also fetch PR context as an action. Use this when the workflow needs pull request context before deciding what to do next. Example:- Get GitHub PRs
- Update journey
- Send Slack summary