Decide which Slack channels, Linear or Jira issues, CI events, and Missions may start work, which identity runs each one, and which human approves every pull request Droid opens.
When you need this
- Engineers want to mention Droid in Slack threads or assign it issues.
- You want automated review or headless runs in CI.
- Pull requests from Droid arrive with no clear owner.
Evaluation criteria
Slack and chat
Which conversations can start work, and as whom?
Look forChoose a Factory organization before connecting Slack. A workspace connects to one organization at a time. The default integration starts thread sessions with saved defaults or a computer picker. A Manager or Owner sets up Delegations on any paid plan. Requests posted in a Slack channel use a shared service account, while direct messages use the sender's Git credentials and connectors.
Linear, Jira, and Teams
Which issues does Droid pick up?
Look forDelegations, available on any paid plan, let engineers assign an issue to Factory or mention @Factory in Linear. In Jira they choose Agents and then Factory, and in a Teams channel they mention @Factory. Put the repository, the outcome, and the verification step in the issue itself.
Headless runs in CI
What may Droid change from a pipeline?
Look forKeep droid exec read-only unless the pipeline needs edits or commands. Set --auto low, medium, or high for the appropriate risk tier. Use ephemeral jobs with short-lived credentials and store FACTORY_API_KEY as a secret. Droid Action reviews GitHub pull requests and GitLab merge requests, skipping drafts.
Missions
Which projects run for hours without a person watching?
Look forUse Missions for bounded, multi-feature work such as a migration, planned with Droid until features, milestones, and validation are agreed. Missions use the same rate limits as sessions and pause at a limit, so set a budget first. The orchestrator can be paused and redirected when a worker stalls.
Ownership and review
Whose name is on the pull request, and who approves it?
Look forRequire two human approvals for pull requests from factory-droid[bot], using a branch rule or status check. In shared delegations, the Factory Droid GitHub App authors the pull request, so the requester can otherwise approve it alone. Factory's documentation sets out this rule.
Recurring automations
Which work runs on a schedule or an event?
Look forName an owner and set a budget for each custom automation. Automations start on schedules, Slack messages, GitHub events, or webhooks. Request Software Factory, a private release, through factory.com/contact to see each automation's repository coverage.
Questions to ask vendors
- Which channels, issue labels, and CI events may start Droid, and who maintains the list?
- Which service account runs shared work, and which repositories can it reach?
- Who approves pull requests requested by people outside engineering?
- Which Missions and automations run unattended, and what is each one's budget?
Red flags
- Requesters approving pull requests Droid opened on their behalf with no second reviewer.
- droid exec running with --skip-permissions-unsafe outside a disposable container.
- A service account with access to every repository.
- Missions started without an agreed plan or a validation step.
Products in this piece
Sources
- Official documentation
- 12
- Factory docs: Delegations
- Factory docs: Slack
- Factory docs: Linear
- Factory docs: Jira
- Factory docs: Droid Exec (Headless)
- Factory docs: Automated Code Review
- Factory docs: Factory Missions
- Factory docs: Missions Planning & Validation
- Factory docs: Custom Automations
- Factory docs: Software Factory
- Factory docs: Deployment Patterns
- Factory docs: Identity & Access