Level 1

Page:

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

Toggle Off —
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)
Page:

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

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

Direct Deployment —
^{(sf) New permissions and reports are deployed post-upgrade by Connected Deployment or by leveraging user credentials. (TBD)}
Page:

Health Check —
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)
Page:

Release Ready —
The packaging and pre-launch production orgs kept in a state of continual release readiness. ^(TBD)
Page:

Toggle Tests —
Validations are performed with all features toggled off, all features toggled on, and with only new features toggled on. ^(TBD)
Page:

Validation —
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)
Page:

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

Tag Repository —
The packaging or production branch in Git is tagged using the JIRA version ID. ^(TBD)
Page:

New Components —
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.
Page:

Merge and Deploy —
The new increment is merged, and deployed to the packaging org or production (using the Ant Migration Tool or SFDX tool). All metadata in the repository is deployed using a blank manifest ^(TBD)
Page:

Milestone TSO Source Template —
(sf) When creating a transient branch, a new trial template is provisioned to represent the new version. ^(TBD)
Page:

Transient Branch —
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)

Level 2

Page:

Auditing —
SetupAuditTrails for subscribers are aggregated via the API and scanned for unhealthy changes. ^(TBD)
Page:

Defect Timebox —
Rather than assign story points, initial work on a defect proceeds within a predefined standard timebox. If the defect cannot be resolved within the timebox, then whether to proceed is reviewed at standup. For example, the timebox may be based on how long it takes to resolve 80% of the defects ^(TBD)
Page:

Fail Events —
(sf) Issues found by failing Apex Unit tests or Selenium tests are posted to cloud-based logging systems, just like production errors and messages. ^(TBD)
Page:

Hammer Tests —
(sf) Subscriber Apex tests are run periodically to detect any new failures. ^(TBD)
Page:

Patch Org Validation —
(sf) Prior to re-launching the preview channel, the GA patch orgs are provisioned early and tested with a deploy to be sure the org provisioned correctly. ^(TBD)
Page:

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

Org Details Object —
(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)
Page:

Rock Steady API —
(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)
Page:

Zero Step Tolerance —
(sf) Any upgrade steps are automated or optional and can be invoked by subscribers. ^(TBD)
Page:

Connected Deployment —
Direct deployment leverages a connected application (and user credentials are not required). ^(TBD)
Page:

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

Version Issue Resolved —
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)
Page:

Version Certification —
^{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)}
Page:

Scope / Docs —
Validation includes the relevant help topics and other documentation (ApexDocs, Developer Guides). ^(TBD)
Page:

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

Level 3

Page:

Ready to Develop Checklist —
(Help text, error messages, sample data ...) ^(TBD)
Page:

Sample Feature Data —
New features provide new sample data to use with new components when appropriate.^(TBD)
Page:

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

Analytics Considered —
Actual and projected feature adoption rates are compared and used as input to roadmap planning. ^(TBD)
Page:

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

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

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

Trust Dashboard —
When reliability issues are detected, the incident is posted to a system health dashboard that all subscribers can access. ^(TBD)
Page:

Score Card —
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)
Page:

Known Issues —
Defects are reported to a public site for awareness and feedback that all subscribers can access. ^(TBD)
Page:

Root Cause Analysis —
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)
Page:

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

Defect Analytics —
Defect dashboards and reports are available in the business org. ^(TBD)
Page:

Error Email Logging —
(sf) Application error emails are forwarded to an inbound email service in the business org. ^(TBD)
Page:

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

Browser not supported