--- schema_version: "1" id: 3ce251bd57f800a3f6ea20c1d409c5d5a3e3ec2ac1066f36833bff72b2eeca85 title: Lifecycle Center Project Best Practices collection: admin version: current locale: en-us portal_url: https://docs.salesforce.com/admin/current/en-us/platform/264-0-0/devops_center_project_best_practices.md canonical_url: https://help.salesforce.com/s/articleView?id=platform.devops_center_project_best_practices.htm&release=264.0.0&type=5 source_site: help.salesforce.com content_type: documentation content_hash: 45093d92d84cb3fa33affa1ecd4f00461a39dd704c801b0dca9c0bf6ef89b957 description: Follow these best practices to plan your Lifecycle Center project. Project is a centralized workspace to manage and deploy a distinct collection of related work items. products: - Salesforce Platform release: "264" --- # Lifecycle Center Project Best Practices Follow these best practices to plan your Lifecycle Center project. Project is a centralized workspace to manage and deploy a distinct collection of related work items. ### Required Editions
Available in: Lightning Experience in Professional (API access required), Enterprise, Performance, Unlimited, and Developer Editions
Not Available in: Government Cloud Plus. Contact your Salesforce account executive for more details.
Not available in: EU Operating Zone. EU Operating zone is a special paid offering that provides an enhanced level of data residency commitment. Lifecycle Center is supported in orgs in the EU that aren’t part of EU OZ, per standard product terms and conditions.
## Determine the Number of Projects Use a single project and a single repository when: - Teams work on the same or dependent metadata and configuration data. - All changes deploy to the same production org. - You require unified visibility across all work. - Development involves interconnected objects and features. ![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 Lifecycle Center doesn't sync metadata and data across projects. To share changes, and surface conflicts early, teams must work on the same project to make sure that metadata and data dependencies remain synced. Create separate projects when: - Teams work on independent metadata and data with no dependencies. - Changes deploy to different production orgs. - Projects follow separate release schedules and governance. - You require isolated hotfix pipelines to bypass standard release cadences. - Teams require operational isolation or prefer to restrict visibility into the active work and changes of another team. ![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 Multiple projects increase management complexity. Create projects judiciously. ## Select Your Project Lifecycle Strategy Decide on a project lifecycle based on your release management processes and cadence. Ongoing projects: Use the same project across multiple sprints and releases. This is the recommended approach for teams with ongoing feature development and stable metadata and data scope. These projects are easier to maintain. For example, long-lived projects are ideal for a team that releases every two weeks and uses one pipeline regardless of the sprint. You can track project performance using DORA metrics and history in Activity History. ![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 DORA metrics are project-specific and don't provide data for all projects in Lifecycle Center. Per-release projects: Create a project for each major release. This approach works better for teams with discrete, time-boxed initiatives or major version releases. This requires more setup work for each release. We recommend that you archive the projects after the release. Hotfix projects: For critical production issues, use a separate hotfix project to support faster turnaround. - Create a project and connect to a pipeline that contains at least a development environment, a testing stage, and a production org. - After you resolve the issue, move all the changes through your standard project pipeline and keep all environments in sync. - Always back sync changes to your main project to prevent branch divergence. ## Manage Inactive Projects You can’t delete a project in Lifecycle Center. Add a z\_ prefix to your inactive project. For example, z\_MyOldProject. This moves the project to the bottom of the list. ## Configure the .forceignore File The .forceignore file determines which changes Lifecycle Center excludes during commit and deployment. Configure .forceignore file in the main branch before building your pipeline so it propagates to all feature branches. To modify a .forceignore file, apply the edits within the work items feature branch. The edits propagate through your pipeline as you promote the work item. See [Exclude Metadata with .forceignore File](https://help.salesforce.com/s/articleView?id=platform.devops_center_exclude_metadata_with_forceignore.htm&release=264.0.0&type=5 "Use the .forceignore file to exclude files or metadata types that you don’t want to commit to the source control or deploy to the target org in your release pipeline. This file makes sure that DX Inspector and Lifecycle Center don’t push or pull unnecessary files, such as IDE configuration files, local test data, or specific profiles, from the development environment."). ## Lifecycle Center Project Strategy Recommendations | SCENARIO | Recommendation | Example | | --- | --- | --- | | Same production org with overlapping metadata and data. | One project, one repository structure | A platform team customizes interconnected objects. Your team develops Sales Cloud features, where developers customize the Opportunity object while others work on Campaigns. Both features use shared custom objects. Use one project because the metadata overlaps. | | Same production org with independent metadata and data. | One project structure (preferred) | Parallel work tracks where an Apex team and a Marketing Cloud connector team deploy to a shared environment. | | Geographically or operationally separate production orgs. | Separate projects | Independent deployments to separate Europe and US production orgs due to data residency requirements. The orgs contain similar apps but deploy independently. Create two projects, one for each production org. | | Urgent, hotfix pipeline path required. | Separate hotfix project | Critical fixes that require an isolated path to bypass the standard release cycle. |