A.5 - Customization Notes

Several aspects of these workflows require project-specific adjustment before use.

The manifest/package.xml path referenced in the drift detection workflow must reflect the project's actual manifest location.

The coverage threshold in the Apex test comment builder is set to 80% - above the Salesforce platform minimum of 75% - and should be adjusted to match the organizational standard agreed at project kickstart.

The cron schedule in the scheduled workflows is set to 0 22 * * * (nightly test runner) and 0 22 * * 2 (weekly surveillance, Tuesday evenings). Both are UTC; adjust for client business hours and to avoid contention with other scheduled activity.

The delta package generation step defaults to a single force-app source directory. Projects using multiple package directories in sfdx-project.json should override the source-dir input on sf-generate-delta.yml or remove it to let sfdx-git-delta infer source directories automatically.

The grep -q '<types>' check against the generated package.xml is the recommended guard for determining whether a delta contains deployable metadata. An empty or minimal package.xml produced when no metadata has changed will lack <types> elements, making this a reliable signal that org-connected steps should be skipped.

The secret scanning workflow (sf-secret-scan.yml) is a placeholder. Replace the run: step with the organization's chosen tool before deployment; the tool's configuration file should be centralized in the configuration repository to ensure consistent credential pattern detection across all project repositories.

The Slack notification workflow posts to a single incoming webhook URL. Teams that need to route different alert types to different channels can extend sf-notify-slack.yml to accept a channel input, or create discrete notification workflows per alert type. For organizations using the Slack GitHub App rather than incoming webhooks, replace the curl step with slackapi/slack-github-action - the inputs interface is stable across either implementation, so calling workflows require no changes.

The branch split between pr-prod.yml and pr-staging.yml exists because they inject different org credentials, not because their gate logic differs. Projects with a third environment class (e.g. a pre-production hotfix branch) can add a third caller file that reuses every workflow in A.2 with a different auth secret. Adding a new environment is a caller-workflow change, not a reusable-workflow change.

The authentication composite action used by the Apex test, compilation, validation, and drift detection workflows is sf-auth-sfdx-url in this reference implementation. Organizations operating under strict governance (see Section 7) should prefer JWT bearer flow by substituting sf-auth-jwt and providing the corresponding secrets.