--- schema_version: "1" id: 1d953f8b28e4a10a069a1510fac1034abbf103bc6ba24a1649bc49266fe048f5 title: Work Outside of DevOps Center (Managed Package) collection: admin version: current locale: en-us portal_url: https://docs.salesforce.com/admin/current/en-us/platform/264-0-0/devops_center_work_item_work_unconnected.md canonical_url: https://help.salesforce.com/s/articleView?id=platform.devops_center_work_item_work_unconnected.htm&release=264.0.0&type=5 source_site: help.salesforce.com content_type: documentation content_hash: e838ba50ab94006f2a65a7b8b111fc2192ccb43ffef534da37f066224d90f9d3 description: After a work item is created, you can choose to do your development work entirely outside DevOps Center (without connecting to a development environment). After changes are merged in the source control system, the promotion is completed in DevOps Center or by using Salesforce CLI. products: - Salesforce Platform release: "264" --- # Work Outside of DevOps Center (Managed Package) After a work item is created, you can choose to do your development work entirely outside DevOps Center (without connecting to a development environment). After changes are merged in the source control system, the promotion is completed in DevOps Center or by using Salesforce CLI. ![Note](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-platform-devops_center-264-0-0-production-enus/166010c3-4c34-4087-92ad-aea917baf524/images/icon_note.png) Note This feature works differently in Lifecycle Center and DevOps Center (Managed Package). This information pertains to the managed package version. To learn about this feature in Lifecycle Center, see [Work Outside the Lifecycle Center UI](https://help.salesforce.com/s/articleView?id=platform.devops_center_work_outside_ui.htm&release=264.0.0&type=5 "Use your preferred local development tools to work on Lifecycle Center work items and commit changes directly to source control. After merging your changes, complete the promotion in Lifecycle Center."). After you select which work item to work on, DevOps Center can create the feature branch or you can create the feature branch using the tools of your choice. Be sure to create the feature branch from the first pipeline stage’s branch, for example, Integration. Work item feature branches must follow this naming convention: ``` https://github.com///tree/WI-000000 ``` ``` https://bitbucket.org///branch/WI-000000 ``` Example: ``` https://github.com/jdoe/Recruiting_App/tree/WI-000015 ``` ``` https://bitbucket.org/sfdc/Recruiting_App/branch/WI-000007 ``` ![Important](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-platform-devops_center-264-0-0-production-enus/166010c3-4c34-4087-92ad-aea917baf524/images/icon_important.png) Important If you’re working directly in the source control repo, delays can occur regarding when these actions happen and when they’re reflected in DevOps Center. If you take subsequent actions on the related objects in DevOps Center before they’re reflected, you're likely to see unexpected or inconsistent behavior. For metadata changes, we recommend that you wait for delayed events to be reflected in DevOps Center. For non-metadata changes, such as updates to the .forceignore file, you can continue with the promotion. 1. In DevOps Center, create a work item or select an existing one to associate with the work. 2. Decide how you want the feature branch created. - To have DevOps Center create the feature branch, click the work item ID. Select **I Want to Develop and Commit My Changes to the Work Item Feature Branch From Outside of DevOps Center**, then click **Proceed**. - Create the branch directly in the source control repository from the first pipeline stage’s branch using the required naming convention. - Use another tool, such as Salesforce Extensions for VS Code, to create a feature branch from the first pipeline stage’s branch using the required naming convention. Be sure to push the feature branch to the project repository. After the branch is created and the event is reflected in DevOps Center, the work item status moves to `In Progress`. You can start your development work. ![Work Item Changes tab if you created the work item without connecting to a dev environment.](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-platform-devops_center-264-0-0-production-enus/166010c3-4c34-4087-92ad-aea917baf524/devops_center/images/work-item-unconnected.png) 3. After you complete your development work, commit your changes in the source control system. If you commit your changes locally, don’t forget to push them to the repository. After you commit your changes, the changes in the feature branch are reflected in DevOps Center. 4. Decide how to create the change request and promote your changes to the first stage in the release pipeline. - Create the change request and promote your changes in DevOps Center. See [Review Changes with Team Members](https://help.salesforce.com/s/articleView?id=platform.devops_center_work_item_review.htm&release=264.0.0&type=5 "When changes for an In Progress work item are committed and ready to share with reviewers, creating a review opens a change request, also called a pull request.") and [Promote Individual Work Items](https://help.salesforce.com/s/articleView?id=platform.devops_center_promotion_work_item.htm&release=264.0.0&type=5 "After a work item is considered “ready to promote,” it’s added to the Approved Work Items list. You can then promote individual work items to the first pipeline stage.") to continue. - Create a change (pull) request and merge your changes in the source control system, then complete the promotion in DevOps Center. See [Promote Changes Merged Outside of DevOps Center](https://help.salesforce.com/s/articleView?id=platform.devops_center_promotion_outside.htm&release=264.0.0&type=5 "If you merge the change request in the source control system, the changes are in a partially promoted state because they’ve been merged but not yet deployed to the associated pipeline environment. You can complete the promotion in DevOps Center or use Salesforce CLI.") to continue. - Create a pull request and merge your changes in the source control system, then deploy the changes to the pipeline stage’s environment using Salesforce CLI. See [Deploy Changes Using Salesforce CLI (Beta)](https://help.salesforce.com/s/articleView?id=platform.devops_center_deploy_changes_cli.htm&release=264.0.0&type=5 "Use Salesforce CLI to deploy changes to a pipeline stage’s environment or to perform a validate-only deployment. You must externally merge any changes in the source control repository before you can perform the deployment using the CLI. While the CLI command runs, you can see the progress of the promotion reflected in the DevOps Center Pipeline Stages tab.") for details. #### See Also - [Work in a Connected Dev Environment](https://help.salesforce.com/s/articleView?id=platform.devops_center_work_item_connected_environment.htm&release=264.0.0&type=5 "When you choose to work in a connected development environment, you perform much of your development and configuration tasks directly in a Developer or Developer Pro sandbox with source tracking enabled. We also support scratch orgs, which have source tracking enabled by default.") - [Promote Changes Merged Outside of DevOps Center](https://help.salesforce.com/s/articleView?id=platform.devops_center_promotion_outside.htm&release=264.0.0&type=5 "If you merge the change request in the source control system, the changes are in a partially promoted state because they’ve been merged but not yet deployed to the associated pipeline environment. You can complete the promotion in DevOps Center or use Salesforce CLI.")