Delegations
Private PreviewDelegate work to Droid from Slack, Linear, Jira, and Microsoft Teams with shared instructions, plugins, identity, and compute.
Delegations lets your team send work to Droid from Slack, Linear, Jira, and Microsoft Teams. Mention Factory in a conversation or delegate an issue, and Droid works on a remote computer using your organization's configuration.
Delegations is in Private Preview. To request access, contact your Factory account team. Available apps and settings depend on your organization's preview access. The default Slack integration remains available outside this preview.
For shared delegations, an administrator configures the instructions, plugins, service-account identity, and compute once. Team members can then delegate work from a connected app without choosing a computer for every request. Slack DMs use the sender's personal identity and connectors instead of that shared identity.
Delegation apps receive requests from your team. Connectors give Droid tools to use while carrying out those requests. Connecting a personal connector does not install the corresponding delegation app for your organization.
Prerequisites
To configure Delegations, you need:
- Private Preview access for your Factory organization.
- The Manager or Owner role in Factory.
- Permission to install or authorize the delegation app in your Slack workspace, Linear workspace, Jira site, or Microsoft Teams organization.
- Service-account access for your organization to configure shared execution.
- Git credentials and any connectors needed by the identity that will run the work.
Team members who delegate work must have a Factory account in the connected organization. Use the same account email in Factory and the connected app so Factory can match the person making the request.
Connect a delegation app
Open Settings → Delegations in Factory. Under Delegation Apps, select Set Up for Org for the app you want to connect. Follow its setup page to authorize the integration. For a connected app, select Configure to return to its setup and management options.
| App | How to delegate work | Setup notes |
|---|---|---|
| Slack | Mention @Factory in a channel or send a direct message. | Invite Factory to channels where it should receive requests. |
| Linear | Assign an issue to Factory or mention @Factory in an issue comment. | Authorize Factory for the workspace and the teams that will delegate work. Follow the Linear setup guide. |
| Jira | Select Agents → Factory on an issue or mention @Factory in an issue comment. | Install Factory for Jira and link the Jira site to your Factory organization. Follow the Jira setup guide. |
| Microsoft Teams | Mention @Factory in a channel. | Link your Microsoft tenant and install the app in Teams. Follow the Teams setup guide. |
A disabled Set Up for Org action means that app is not available for your organization yet.
Personal and shared identity
Slack distinguishes personal conversations from shared channel work:
- Direct messages to Factory run as the person sending the message, with their personal Git credentials and connectors.
- Channel requests using the Apps configuration run as its service account, with that account's Git credentials and connectors, not the sender's personal connections.
DMs can still use the Apps configuration's execution template, instructions, and model defaults. A template-backed DM runs on a computer owned by the sender, not the service account's pool. Without a template, it falls back to the default Slack flow's saved settings or computer picker, including any explicit Run as choice. See personal DMs and shared channels.
Configure delegated sessions
Under Delegation Configs, select Edit on Apps. This configuration powers shared work delegated from Slack, Linear, Jira, and Microsoft Teams. Its service-account identity applies to shared channel and issue delegations; Slack DMs use the personal identity described above.
Factory creates a default configuration, service account, and execution template when setting up eligible organizations. Review those defaults before delegating work. If setup could not complete, use the configuration wizard to select an active identity and compute.
- 1General
Choose the Default model and Default reasoning level. Leave the model on Auto Model to use Factory Router.
Add Custom Instructions for behavior that should apply to every delegated session. For example, specify which tests to run, what a completion summary should contain, or when Droid should open a pull request.
The configuration's name is fixed, and Access is Everyone. Custom groups are coming soon.
- 2Plugins
Add plugins that delegated sessions need. Enter the plugin name, choose its marketplace, and select Add.
Marketplaces must first be registered under Enterprise Controls → Plugins. Plugins enabled organization-wide are included automatically. A plugin disabled organization-wide stays disabled even if it is listed in this configuration.
- 3Identity
Choose Use Existing Service Account or New Service Account. The selected account must be active.
Shared delegated sessions run as this service account, not as the administrator editing the configuration. Use the identity's controls to configure Git credentials, connectors, API keys, and computers. Make sure it can access the repositories and external tools the work requires.
- 4Compute
Choose Dynamic and select an execution template, or choose Persistent and add computers to the service account's pool.
Select Finish to save. Dynamic compute requires a template. Persistent compute requires at least one computer owned by the selected service account.
Set personal delegation defaults
Team members can open Settings → Session Defaults → Delegations to set personal defaults for the work they delegate:
- Default delegation model and Default delegation reasoning level: a personal model selection overrides the Apps configuration's model when organization policy allows it. Its reasoning preference applies to that selected model. Choose Org default to use the configuration's model and reasoning settings instead.
- Your custom delegation instructions: instructions added to every delegation you start, including follow-up messages in those sessions. They are added after the Apps configuration's instructions and do not replace or override them. You can save instructions while leaving the model on Org default.
These defaults follow the person who starts the delegation, so they apply to Slack DMs, Slack channel requests, Microsoft Teams channel requests, and Linear and Jira issues you delegate. They change the model and instructions, not identity or connector access: config-backed Slack DMs use the sender's personal identity and connectors, while shared channel and issue delegations use the service account's. Personal defaults do not make a shared session run as the requester.
Delegate your first task
Start with a small, reviewable request in a connected app. Include the repository, the desired outcome, and how Droid should verify the result.
For example, mention Factory in Slack or Teams:
@Factory Investigate the failing checkout test in the storefront repository. Fix the cause, run the relevant tests, and open a pull request with a summary of the change.
In Teams, include the relevant context in the mentioning message. Droid does not yet receive earlier channel or thread messages. See Delegate a task from a channel.
For Linear or Jira, put those details in the issue description, then assign the issue to Factory or mention Factory in a comment. In Jira, use the Agents picker or an issue comment.
Review Droid's response and any linked session or pull request. Send follow-up instructions through the originating conversation or issue where supported. Check the test results and proposed changes before merging.
Require independent GitHub review
For shared delegations that use the Factory Droid GitHub App, Factory is the pull request author, not the teammate who requested the work. GitHub prevents authors from approving their own pull requests, but the requester can still approve a Factory-authored pull request. With only one approval required, the requester can satisfy the review requirement and, if otherwise permitted, merge without another person's review.
To require another reviewer, configure a branch protection rule or ruleset for each target branch in GitHub:
- Apply the requirement to all pull requests: Set the required approval count to two. This also affects pull requests opened by teammates.
- Apply the requirement only to Factory-authored pull requests: Add a required status check that enforces two human approvals for pull requests opened by
factory-droid[bot](the Factory Droid GitHub App).
See GitHub's documentation on protected branches and status checks.
Troubleshooting
Related resources