Procore App Version Promotion
Overview
Promote the Procore app contract and the integration deployment as one reviewed release. Permission changes, installation steps, OAuth credentials, endpoint compatibility, and customer communication must align with the same semantic version.
Prerequisites
- Immutable integration release and matching Procore app version
- Permission and component diff, release notes, migration plan, and rollback owner
- Sandbox installation, test company, production approver, and observation window
Instructions
Step 1: Freeze the release
Record source release identifier, app manifest version, endpoint inventory, configuration schema, and generated artifacts. Refuse moving tags or unreviewed builds.
Step 2: Review contract changes
Classify semantic version impact and inspect added permissions, components, callback URLs, post-install steps, and customer-facing behavior.
Step 3: Verify in sandbox
Install the version using the correct environment key, exercise authentication, required reads, expected denials, mutations in disposable data, webhooks, and cleanup.
Step 4: Approve promotion
Present evidence, permission diff, release notes, known limitations, support plan, and rollback. Require the authorized operator to promote the reviewed version.
Step 5: Deploy and canary
Deploy the matching integration release to a bounded tenant set, verify token acquisition and read-only access, then enable controlled business processing.
Step 6: Observe and settle
Monitor API activity, Integration Health, errors, rate budget, webhook deliveries, and backlog. Roll back the application release or integration according to the predeclared boundary.
Authentication
Deployment verification uses OAuth 2.0 credentials for each environment and never copies sandbox tokens into production. Production credential issuance and rotation stay within the Developer Portal and approved secret store.
Tool Discipline
Use Read and Grep to inspect release artifacts, manifests, diffs, and evidence. Use Write or Edit only for the approved release record, configuration, test, or receipt; the actual Procore promotion requires an authorized portal operator.
Output
- Immutable release and app-version evidence
- Permission diff, sandbox proof, promotion approval, and canary results
- Observation, rollback, and customer-impact receipt
Return exact versions, approvers, test results, rollout scope, health signals, and final disposition.
Examples
A manifest adds a new project-tool permission, so the release is classified accordingly and tested against both allowed and denied projects. The production canary does not begin until the portal version and deployed integration share the reviewed release.
Error Handling
| Failure | Response |
|---|---|
| Manifest and deployment differ | Stop rollout and rebuild from the immutable reviewed release. |
| Permission diff is unexplained | Reject promotion until each new capability has an owner and test. |
| Sandbox proof fails | Repair and create a new reviewed version rather than editing evidence. |
| Canary health degrades | Halt expansion and execute the declared rollback boundary. |