There are three main approaches to integrating Fragment into your workflow, depending on whether you want to use Fragment as the primary source of truth for your tickets or synchronize with an existing ticketing system.
ScenarioMethodDescription
Already have ticket-like objectsSynced tasksMap your tickets to Fragment tasks.
Events should create tasksNative tasksUse triggers to create tasks on Fragment.
Zero-code setupManual task creationUse Fragment’s UI for task creation.

​
Guidelines

Try to design your integration so that processes can evolve with minimal engineering help.
TL;DR:
  • Push all available metadata to Fragment
  • Let Fragment handle ticketing (queues, assignees, etc.)
Push all available metadata For example, suppose tasks may be created with a country field. Even if unused at first, the requirements might change later and require to route tasks from different countries to different teams. If you pushed the country field since day one, the Ops team can simply update the queues directly in Fragment without requiring engineering help. Let Fragment handle ticketing (queues, assignees, etc.) It might be tempting to push queue or assignee information directly when creating the task. However, if the requirements change later, engineering time will be required. Instead, push metadata that enables Fragment’s workflows to route the task to the right team. Fragment workflows can be updated in minutes by non-technical team members.

​
1. Synced tasks

for ticket in tickets:
    upsert_task_from_ticket(ticket.id, ticket.data)
See Sync with existing objects for more details. Use this approach when you already have a ticketing system (Zendesk, Jira, internal back office, etc.) and want to use Fragment as a processing interface while keeping your existing system as the source of truth. Benefits:
  • Retain control over the ground truth
  • Clear 1:1 mapping between Fragment and your existing system

​
2. Native tasks

if user.status == "new":
    create_onboarding_task_for_user(user.id)
See Trigger task upserts for more details. Contrary to the previous approach, you don’t have ticket-like objects in your system. Instead, you want to create tasks on Fragment reacting to some triggers (button click, background job, event, etc.). Use this approach when Fragment serves as the primary source of truth for your tasks. This gives you full control over the task lifecycle and allows you to leverage Fragment’s complete feature set. Benefits:
  • Offload complexity of ticket management to Fragment
  • No data duplication
  • Clear separation of concerns

​
3. Manual task creation

Including a link directly inside your back-office can be a quick and efficient way to let your operators create tasks on Fragment.
See Manual task creation for more details. Use this approach when you don’t want to integrate with the API or don’t have an existing ticket system. Benefits:
  • No development required
  • Quick setup for teams without technical resources
  • Built-in form validation and UI