Crucial defects are quickly repaired and (MP) made available as patch versions to affected subscribers. ^(TBD)

Optional features promoted to GA or Beta in a release can be deployed in an activated or deactivated state and toggled on or off by the subscriber. ^(TBD)

(sf) Custom metadata feature toggles may be hidden from the subscriber and activated through the LMA. ^(TBD)

When Direct Deployment is used, scale agents on a platform like AWS, so that many subscribers can be upgraded at once. ^(TBD)

The packaging and business orgs continue to pass the Salesforce Security Health Check following each major release, with a score of 80% or above. New subscriber orgs are reviewed with the Salesforce Optimizer before launch. ^(TBD)

Validations are performed with all features toggled off, all features toggled on, and with only new features toggled on. ^(TBD)

The latest work increment, is examined at the close of each sprint, to determine whether the version is ready-for-primetime. For MPs, a milestone version is validated. For CSs, a full staging sandbox is validated. For MPs, patch versions are run through the same gauntlet as major versions. ^(TBD)

^{Install the new version into the Preview TSO, which generates production-like environments. (TBD)}

Once the new increment is deployed, update the change log to list any new components (classes, fields, and so forth) being added to the version, by using a Javascript macro to scrape the package details page.

To freeze the work increment being released, a temporary branch is created from develop, and a pull request created from the transient branch to packaging or production. ^(TBD)

(sf) At the end of the sprint, a new development TSO templates is provisioned, in case it is needed for patch development. ^(TBD)

^{(sf) On merge to develop, the updated develop branch is validated (checkOnly) with the packaging org or production branch. (TBD)}

^{Peer developers review and test all changes before code and sample data is merged back to version control, following a test plan that is created for each issue in Confluence. (TBD)}

Help for this Page is extended for new tabs, updated as needed, and linked to Help Site. ^(TBD)

New reporting examples are included with new features, as appropriate, and distributed through Direct Deployment. ^(TBD)

(sf) Subscriber Apex tests are run periodically to detect any new failures.  ^(TBD)

(sf) The AppExchange entry is updated to the latest version for each new GA major version, without concern of prompting a security review.  ^(TBD)

(sf) To track additional detail about subscriber orgs, a custom object in the business org is linked to the LMA and the subscribers Account object. The org details aggregates the API applications installed for each subscriber, the instance, the my domain name, the production org ID, as well as the staging/preview sandbox IDs, and refresh history. Ideally, an automation posts an alert whenever a new org is added, to queue followup actions. ^(TBD)

(sf) Global components are stable with a low regression rate, including behaviors of Global Apex class methods and variables, Apex triggers, custom metadata, custom objects, fields, validations, and workflows. ^(TBD)

(sf) Any upgrade steps are automated or optional and can be invoked by subscribers. ^(TBD)

The progress being made on a major version rollout is tracked in a shared checklist and/or Agile board. ^(TBD)

The issue for the version is resolved in the New Version issue tracker and indicates its resolution status (failed certification, certified but not deployed, certified and deployed). ^(TBD)

^{Each new version is validated following a detailed checklist and exploratory test plan. If all checklist items pass, the version is certified for production use. Uncertified versions are deprecated. (TBD)}

Validation includes both regression tests and feature acceptance tests, in automated and exploratory form. ^{#TestLikeACustomerr (TBD)}

Update the change log to list the issues for the new version. (May be done in GNG Baseline.)

The version creation and validation process is tracked in a shared checklist and/or Agile board, and included in the issue tracker. ^(TBD)

^{Selenium Nightwatch tests are included where appropriate to assure that the user interface will continue to work as expected. (TBD)}

Common security issues are checked as part of peer review or static analysis ^(TBD)

Other shared components are documented with Octopus. ^(TBD)

The Preview and GA help sites are updated within each sprint to cover new tasks, topics, and references meaningful to end-users.  ^(TBD)

(Help text, error messages, sample data ...) ^(TBD)

New features provide new sample data to use with new components when appropriate. ^(TBD)

New changes are specified with extensibility for multiple subscribers in mind, including the mock customer. ^(TBD)

Subscribers Ideas play a strong role in steering the future roadmap, along with a strong internal vision of the product's future. ^(TBD)

Subscribers are able to post feature enhancement requests ("Ideas") to a forum for peer and product management review. ^(TBD)

Usage metrics and logs are continually scanned to detect statistically significant variations in error volume, creating a "production immune system". ^(TBD)

A set of leading and lagging metrics are used to predict and then review the success of a CS project or MP major version and compared with actual results prior to the next event. ^(TBD)

To ensure the quality and improvement of our change management process, and to prevent previously discovered problems from recurring, we perform a root cause analysis (RCA), by asking five whys. ^(TBD)

Defect reports and repairs are closely monitored and used as a key performance indicator. ^(TBD)

(sf) FeatureSetupAuditTrail for subscribers are aggregated as part of Push Metrics. (Needs to be considered in the context of the Feature Management pilot.) ^(TBD)

Feature usage and adoption is automatically monitored and subscriber orgs push configuration settings, logs, and statistics back to the MP business org. For Salesforce, the metrics include data storage used, installed packages, and Lightning adoption. For Communities, metrics include license counts and Community logins. ^(TBD)

New implementation setup is streamlined through use of a configuration wizard that collect and updates settings. ^(TBD)

Any change to feature configuration (including validation rules) is recorded in a supplemental audit trail log and made available as part of Push Metrics. ^(TBD)

Subscribers can select their own upgrade slot within a window, or accept a default upgrade date. ^(TBD)

Queue automated deployments of new versions from build server o to individual subscribers or subscriber groups. On Force.com, Deploy Fom Hub queues deployments form the business org. ^(TBD)