> ## 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. # External tasks and issues > Create and track delivery work in GitHub, Jira, Linear, and Notion without losing the customer context that made the work matter. Linked tasks are how journey work moves into delivery tools without losing the customer reason behind the work. Custory is not trying to replace your delivery tool. It is trying to keep the customer reason, journey context, and implementation state connected. ## Supported platforms Custory supports linked task connections with: * GitHub * Jira * Linear * Notion These links are useful whether the task was created manually from an item or generated through an automation. ## When to link a task Use a linked task when an item needs real follow-through outside Custory. Common examples: * An opportunity becomes a Linear issue * A solution becomes a Jira ticket * A customer-facing bug becomes a GitHub issue * A content or process follow-up becomes a Notion item ## Why linked tasks matter The handoff from customer context to delivery is where many teams lose fidelity. The pattern usually looks like this: 1. The team identifies a real problem 2. Someone creates a task elsewhere 3. The delivery work gets renamed, reframed, or reprioritized 4. The original context disappears Custory reduces that drift by keeping the task tied back to the item it came from. ## Creating a linked task from an item From an item, you can create a task in a supported external system. The handoff is strongest when: * The item already has a clear title and description * The right integration is connected * The journey has integration defaults where relevant Depending on the platform, Custory can prefill creation context such as: * GitHub repository * Jira project and issue type * Linear team * Notion database Those defaults are especially helpful for smaller teams that want consistent routing without extra setup every time. `Add screenshot of the linked task creation dialog and linked task card on an item here` ## Journey-level integration defaults Custory supports per-journey defaults for task destinations. That means a journey can remember the most likely external target, such as: * the default GitHub repo for this product area * the Jira project for this journey * the Linear team that owns this surface * the Notion database used for this stream of work See [Journey settings](/journey-settings) for setup guidance. ## What stays visible after linking Once a task is linked, the item can continue to show delivery context such as: * external task title * external task status * direct link back to the source tool This helps the team review implementation progress without leaving the journey every time. ## Sync behavior Custory keeps linked task details more current over time. Current sync coverage focuses on: * Status sync This works across GitHub, Jira, Linear, and Notion so the item stays closer to the current reality of the delivery system. Task titles are stored on the link and can update when Custory changes the external task through the integration. ## Notifications about external changes When linked task details change through sync or integration updates, the relevant people can be notified about important updates such as: * Status changes * Title changes from integration-backed edits This is valuable when founders or PMs are stewarding journey quality but do not want to poll delivery tools manually just to see what moved. ## How to use linked tasks well ### Create the task from the item when possible That gives the best chance that the original customer context travels with the work from the beginning. ### Keep the item current even after handoff A linked task does not make the item obsolete. The item still holds the customer reasoning, related evidence, linked items, and outcome context. ### Use the item for the why, and the external tool for the how Custory should hold: * The customer problem * The evidence * The linked opportunity or solution * The metric or expected outcome Your delivery tool should hold: * Execution detail * Technical implementation * Delivery coordination ## Best platform use cases ### GitHub Best when the work maps directly to engineering execution and code-facing follow-up. ### Jira Best when the team already runs delivery through project and issue-type structure. ### Linear Best for lean product teams that want fast issue creation and ownership routing. ### Notion Best for content work, process follow-up, or lighter-weight non-engineering execution. ## Handoff mistakes to avoid A thin item usually becomes a thin task. Add enough description first so the handoff is clear and the delivery team understands the customer reason behind the work. If the task changes scope, update the linked task through Custory when possible or review the source tool before relying on the original wording. The linked item should still explain the customer reason even if the delivery title changes. A linked issue only proves the work was created. Review the status, comments, and linked metric to understand whether the customer problem is actually moving. ## Next step Read [Item details and fields](/item-fields) to strengthen item context before handoff. Read [Automations](/automations) if you want task creation to happen automatically.