# Remote Delegations Delegate work to Droid from Slack, Linear, and Jira with shared instructions, plugins, identity, and compute. Remote Delegations lets your team send work to Droid from Slack, Linear, and Jira. Mention Factory in a conversation or delegate an issue, and Droid works on a remote computer using your organization's configuration. Remote 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](/remote-delegations/slack#default-slack-flow) 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](/harness/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 Remote 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, or Jira site. - 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 → Remote 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](/remote-delegations/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](/remote-delegations/linear#connect-your-linear-workspace). | | [Jira](/remote-delegations/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](/remote-delegations/jira#install-and-connect-factory-for-jira). | 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](/remote-delegations/slack#personal-dms-and-shared-channels). ## Configure delegated sessions Under **Remote Delegation Configs**, select **Edit** on **Apps**. This configuration powers shared work delegated from Slack, Linear, and Jira. 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. Choose the **Default model** and **Default reasoning level**. Leave the model on **Auto Model** to use [Factory Router](/model-independence/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. 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. 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. 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 model defaults Team members can open **Settings → Session Defaults → Delegations** to set **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. These preferences can apply to both Slack DMs and channel requests. They change model selection, not identity or connector access: config-backed Slack DMs use the sender's personal identity and connectors, while shared channel delegations use the service account's. Selecting a personal model does not make a channel session run as the sender. ## 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: > @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. 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](/remote-delegations/jira#delegate-an-issue). 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](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) and [status checks](https://docs.github.com/en/pull-requests/reference/status-checks). ## Troubleshooting Confirm that your organization has preview access and that you are a Manager or Owner. Remote Delegations settings are not available in airgapped deployments. If the page is visible but Remote Delegation Configs is missing, ask your Factory account team to check service-account eligibility. Make sure the email on your connected-app account matches your Factory account email, and that you belong to the connected Factory organization. Then retry the request. An administrator must choose an active service account in the configuration's Identity step. Check that its Git credentials and connectors are ready for the work. Check that the selected execution template still exists and has a ready build. If provisioning fails, retry. If Factory reports that managed compute is unavailable, ask an administrator to review compute policy and usage limits. For Persistent compute, check that computers belong to the selected service account and have finished provisioning. Bring-your-own machines must be online with a current Droid daemon. Retry after a session finishes. An administrator can add computers or adjust the per-machine parallel worker limit. Increasing the limit means more sessions share the same resources. Configure service accounts and Git credentials for shared work. Connect your own computers for persistent execution. Set up the default Slack integration or the Remote Delegations preview flow. Connect Factory and delegate work from Linear issues.