Slack
Connect Factory to Slack, use the default session flow, and distinguish personal DMs from shared channel delegations.
Connect Factory to Slack so Droid can work with Slack conversations and team context.
The existing Slack session flow remains the default for most organizations. After connecting the app, the session flow depends on your organization's configuration:
- Default Slack flow: start sessions from Slack threads using saved defaults or the computer picker. Existing channel configurations and explicit service-account choices still apply.
- Delegations flow: for organizations in the Private Preview, channel requests use the shared Apps configuration. Slack DMs use your personal identity and connectors, rather than the configuration's service account.
This page covers the Factory Slack app. A personal Slack connector gives Droid tools to use inside sessions; it does not install the app in your workspace.
If an existing Factory Slack install lacks permission to read images or upload files, rerun its authorization flow to enable those capabilities. A Slack admin may need to approve the updated permissions.
Prerequisites
To install or manage the Factory Slack app, you need:
- A Factory account with the Manager or Owner role
- Admin access to your Slack workspace
- Ability to install apps in your Slack workspace
- Access to Settings → Delegations in Factory
If Delegations is missing from Settings, contact your Factory account team to check access. The current app no longer offers Slack installation under Settings → Organization. An existing Slack installation can still use the default session flow.
Integration steps
- 1Access Slack integration settings
Open Settings → Delegations. Under Delegation Apps, find Slack and select Set Up for Org, or Configure if it is already connected.
- 2Connect or reconnect Slack
On the Slack setup page, click Connect. For an existing installation, click Manage, then Reconnect to refresh its permissions.
- 3Authorize Factory's Slack app
You'll be redirected to Slack. Review the requested permissions and click "Allow" to authorize Factory access to your Slack workspace.
- 4Select the workspace
If you belong to multiple workspaces, select the workspace you want to connect to Factory.
- 5Confirm the integration
After authorization, you'll be redirected back to Factory. Verify that the integration status shows as "Connected".
- 6Add Factory to channels
In your Slack workspace, add the Factory app to relevant channels by typing
/invite @Factoryin each channel.
Default Slack flow
Without a shared delegation configuration in use, Factory starts sessions using your saved defaults or asks you to choose a computer. Existing legacy channel configurations and explicit Run as selections can choose a service account instead.
Verification
To ensure the integration is working correctly:
- 1Mention
@Factoryin a thread within a channel where the app has been added. - 2Verify that Factory responds with a link to open the conversation in Factory.
- 3Click the link and confirm that the Slack thread content appears in your new Factory session.
- 4If you reran the install flow for the latest permissions, test with a thread that includes an image attachment and confirm Droid can use it as context.
- 5If your workflow posts results back to Slack, confirm Droid can upload a generated file or short result video to the thread.
Capabilities
With the Slack integration, you can:
- Mention
@Factoryin any Slack thread to start a Droid session from that thread - Continue the session on Web or Desktop from the View on Desktop and View on Web buttons when it runs as you
- Import full Slack thread context into Factory by clicking the provided link
- Include supported image attachments from Slack as session context
- Have Droid post messages, generated files, artifacts, and result videos back to Slack
- Send follow-up messages and attachments from Slack into an active Droid session
- Choose from the available models, including Claude, GPT, Gemini, and Droid Core
- Pick the model when you start a session, set a default model per channel for Auto-Run and service-account workflows, or let Factory Router pick the best model automatically
- Reference Slack threads in Factory by pasting a thread URL into a Factory chat
When creating a PR, the Slack integration will also use a subagent to handle CI so the agent can respond faster.
When a Slack thread is imported, Factory has access to the entire conversation history and uses it as context.
Slack settings
Existing legacy channel configurations can continue to select Run as, Incident Response, Machine Type, Computer or Workspace, Session Visibility, Model, and Custom Prompt. Standard @Factory mentions do not require a channel configuration.
The current Slack setup page manages the app connection, not the legacy channel settings table. For new channel-triggered workflows, use Incident Response or Automations.
Service accounts
Use service accounts when Slack sessions should run from a shared identity and a preconfigured Droid Computer instead of the Slack user who mentions Factory. This is useful for incident, operations, or release channels that need consistent credentials and tool access.
Before using a service account with Slack, make sure:
- Service accounts are enabled for your organization.
- The service account is active.
- The service account owns at least one Droid Computer.
- The Factory app has been invited to the Slack channel.
An existing channel Run as configuration uses the selected service account's identity and computers. Its Auto-Run settings can also specify a prompt, model, and visibility for automated channel workflows.
For ad hoc Slack sessions, the computer picker can also show a Run as selector. Choose a service account, pick one of its computers, and optionally save it as your default for future Slack mentions.
A session that runs as a service account belongs to that account, not to the person who mentioned Factory. Its Slack status message doesn't include View on Desktop, View on Web, or the session settings menu. Follow up in the Slack thread instead.
Delegations flow
Delegations is in Private Preview. To request access, contact your Factory account team. Existing Slack installations can continue using the default session flow without the shared configuration.
In this flow, the organization's Apps configuration supplies the execution settings. Channel delegations use its service-account identity and compute. DMs run as the person messaging Factory, using their personal credentials and connectors.
Preview prerequisites
For shared channel delegations, you need:
- Delegations Private Preview access for your Factory organization.
- Service-account access and an active service account with the Git credentials and connectors needed for the work.
- A configured execution template for Dynamic compute, or computers owned by that service account for Persistent compute.
Each team member who delegates work must have a Factory account in the connected organization. Their Slack account email must match their Factory account email.
Connect Slack and configure delegated sessions
Use the integration steps above to connect Slack. Then configure shared execution:
- 1Review the Apps configuration
In Settings → Delegations, under Delegation Configs, select Edit on Apps. Review the default model and reasoning level, custom instructions, plugins, service-account identity, and compute.
Eligible organizations receive a default configuration, service account, and execution template. Review those defaults before use, or complete the configuration wizard if setup could not finish. Follow Configure delegated sessions for the full setup.
This configuration is shared across delegation apps, not scoped to one Slack channel. Its service account supplies the identity and connectors for shared channel delegations, not personal DMs.
- 2Invite Factory to channels
In each Slack channel where your team will delegate work, run
/invite @Factory.
Delegate and follow up
Mention @Factory in a channel where the app has been invited, or send the app a direct message. Include the repository, desired outcome, and how Droid should verify the result:
@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.
Droid runs the work with the identity appropriate to the conversation. Review its response and any linked pull request. Slack links to the session only when it runs as you. Channel delegations run as the service account, so Slack doesn't link them. DMs run as you, so Slack links to them. Continue with follow-up instructions in the same Slack conversation, or in the code channel if Droid opened one. Check the test results and proposed changes before merging.
Code channels
A code channel is a Slack channel dedicated to one Factory session. Instead of following the work in a thread, your team gets a channel for the task. Factory posts its updates there, and the channel shows the repository and branch Factory is working on and a diff of its changes.
Code channels are available for delegated sessions that a person starts. Automation and Incident Response runs stay in their thread. Code channels also depend on Slack's own code channels feature. If your workspace does not have it yet, or your Factory Slack app was installed before code channels were available, sessions stay in the thread. To grant the code channels permission to an existing installation, reconnect the app using the integration steps.
A session moves into a code channel in one of two ways:
- Droid moves it. Before starting substantial work, such as a multi-step change across several files, a pull request, or extended debugging, Droid opens a code channel named after the task. Droid stays in the thread for questions, small fixes, and conversational replies, or when you ask it to stay there.
- You ask for one with
!new. Post@Factory !new <task>to start a new session in its own code channel. Send@Factory !newin an existing session's thread to move that session into a code channel. In DMs and code channels, you can leave out the@Factorymention.
When a session moves, the original thread gets a "Working on this in #channel" notice. Replies in that thread no longer reach the session, so Droid asks you to send them in the channel instead.
Work in a code channel
- Post top-level messages in the channel. You do not need to mention
@Factory. Droid reads the channel's messages, replies top-level, and stays quiet when a message is not meant for it. - Droid keeps the repository and branch shown in the channel current as it switches repositories or branches.
- When Droid has changes, Slack shows a diff of its branch against the base branch. Factory withholds the diff when it may contain secrets or is binary or too large, and shows a notice instead.
- Questions from Droid appear in the channel. Answer them with a regular message.
Archive a code channel
When the work is done, ask Droid to archive or wrap up the channel. Droid posts a summary of the outcome, pull request links, and anything left open, then archives the channel. Droid does not archive a channel on its own initiative.
If a code channel has no activity for 7 days, Factory posts a warning and archives the channel 24 hours later unless someone sends a message. Archived channels stay in Slack as a record of the work. To pick the work back up, mention @Factory in the original thread.
Personal DMs and shared channels
For sessions started through the Apps configuration, the Slack conversation determines whose access Droid uses:
| Where you send the request | Session identity | Credentials and connectors |
|---|---|---|
| A direct message to Factory | Your personal Factory identity | Your personal Git credentials and connected apps |
An @Factory mention in a channel | The Apps configuration's service account | That service account's Git credentials and connected apps |
Connect the tools you want to use in DMs under your own Factory account. For shared channel work, configure them on the service account. Mentioning Factory in a channel does not pass your personal connectors to the shared session.
A DM can still use the Apps configuration's execution template, instructions, and model defaults. When a template is available, Factory provisions a computer owned by you instead of using the service account's computer pool. If the configuration has no template, the DM falls back to the default Slack flow's saved settings or computer picker, including any explicit Run as choice.
Slack commands
Start a message with a command to control Factory instead of sending a task. In channels, mention @Factory before the command, for example @Factory !help. In DMs and code channels, send the command on its own.
| Command | What it does |
|---|---|
!new <task> | Starts a new session for the task in its own code channel. Without a task, Factory opens the code channel so you can describe the work there. In an existing session's thread, !new moves that session into a code channel. |
!connect | Replies with SSH instructions for the computer running an existing session. Start a session first, then send !connect in its thread or code channel. In channels, only you can see the reply. |
!help | Lists the available commands. |
Send !help and !connect on their own. If a message has any other text, Factory treats it as a normal request.
Best practices
- Add the Factory app only to channels where development discussions occur.
- Use threads rather than channel messages when mentioning Factory. For larger tasks, Droid may move the work into a code channel.
- Provide sufficient context in the Slack thread before mentioning Factory.
- Regularly review the permissions granted to the Factory app in your Slack settings.
Troubleshooting
Visit Factory's Trust Center for compliance documents, certifications, and security resources
Review Factory's Privacy Policy and Terms of Service.
Related resources