Platform Lifecycle and Deployment Architect Exam Prep - Operating

Operating consists of 10% of total score in Salesforce Platform Lifecycle and Deployment Architect Exam. The topic covers risks, strategies, direct changes and managing common release artifacts.

NOTE

Most of the content in this work was generated with the assistance of AI and carefully reviewed, edited, and curated by the author. If you have found any issues with the content on this page, please do not hesitate to contact me at support@issacc.com.

⚙️ OPERATING

Making Direct Changes in Production + Managing Common Release Artifacts

---

⚡ Making Direct Changes in Production

🧩 Topic	💡 Key Points
💻 Sandboxes	Safe risk-free environments to test high-impact changes (code, workflows, global features)
🏭 Production	Only for low-impact changes (fields, picklists, reports); needs caution & validation
⚠️ Implications	Risk of errors, conflicts with concurrent changes, compliance issues, data loss
🛡️ Precautions	Double-check → Communicate → Phased release → Training users
🧠 Coding	Cannot be done directly in production, must be done in sandboxes

What are best practices for direct prod changes?

• Do it only for minor, low-risk updates

• Review & approve by stakeholders

• Use a hotfix process if urgent

• Document everything

• Update sandboxes & VCS after making change

---

⚠️ Risks, Strategies, and Tools

⚠️ Risks	🧠 Strategies	🛠️ Tools
Bypass testing → Errors	Emergency hotfix workflow	Deployment tools (Salesforce CLI, Change Sets)
Conflict with other changes	Thorough review & authorization	Sandbox refresh cycles
Compliance & data security	Communication & training	Version control (Git)

---

🧩 Integrating Direct Changes into ALM

How to integrate direct prod changes into ALM?

• Create a strategy to retroactively record changes

• Update downstream environments (sandboxes)

• Validate in sandbox afterward

• Commit metadata to source control

• Communicate changes to all stakeholders

What extra steps ensure smooth adoption?

• Provide user training on the change

• Monitor for side effects

• Coordinate with dev teams for next sprint

---

💼 Business Scenarios (Direct Changes)

Scenario	Situation	Solution
⚡Urgent data field bug	Replace a defective field directly in prod	Do so with close review & oversight to minimize brand damage
🐞Apex bug in prod	Bug from old Apex class, strict compliance rules	Create hotfix branch, get stakeholder approval, deploy safely
⚙️Minor change policy	Regulated prod, no CI/CD	Require documentation, security review, stakeholder approval, then update sandboxes
⚡Unit tests failing	Consultant added field only in prod	Do daily metadata backups to VCS, refresh sandboxes, use Change Sets to sync

---

🏗️ Multi-Org: Managing Common Release Artifacts

Approach	Key Idea
📁 Source-Driven Dev	Use Git as source of truth, branch & merge across orgs (CI/CD)
📦 Packages	Use Managed/Unlocked for modular delivery, or Unmanaged for backup
🧩 Metadata API	Use retrieve() / deploy() with project manifest (package.xml)
📨 Change Sets	Good for small connected org deployments (sandbox → prod)
🧠 Other Tools	.zip bundles, Salesforce CLI, RTM, and 3rd-party backup/rollback tools

When to use each method?

• Source-driven → many orgs, complex collaboration

• Metadata API → direct control over specific components

• Packages → versioning, modular reuse, backups

• Change Sets → simple admin-friendly small moves

---

💼 Business Scenarios (Multi-Org)

Scenario	Solution
📨 Consultant can’t access prod	Use Metadata API retrieve() → send .zip + package.xml → team does validate → quick deploy with CLI
📜 Unknown old Apex class	Use Requirements Traceability Matrix (RTM) to find its purpose
🛡️ Regulated rollback & backups	Evaluate 3rd-party or AppExchange tools (since unmanaged pkg backup is limited)

---

🧠 Quick Decision Guide

Need	Best Approach
Urgent fix	Emergency hotfix + stakeholder review
Low-risk config change	Direct in prod + documentation + sandbox sync
New feature dev	Sandbox → ALM pipeline (Git, CLI, CI/CD)
Multi-org artifact sync	Source-driven + Metadata API
Metadata rollback & backup	Unmanaged pkg + 3rd-party tool

📈 Flow Charts

1) Decide where to make the change

flowchart TD
    A[New request] --> B[Assess impact and risk]
    B --> C[High impact or any code]
    B --> D[Low impact config]
    C --> E[Use sandbox]
    D --> F[Consider direct change in production]

2) Safe direct change in production checklist

flowchart TD
    A[Plan change] --> B[Review dependencies]
    B --> C[Get stakeholder approval]
    C --> D[Communicate to users]
    D --> E[Create quick backup or export]
    E --> F[Implement change in production]
    F --> G[Validate with super users]
    G --> H[Monitor and roll back if needed]
    H --> I[Document change]
    I --> J[Sync to sandboxes and version control]

3) Emergency hotfix path

flowchart TD
    A[Detect critical issue] --> B[Open hotfix ticket]
    B --> C[Create hotfix branch]
    C --> D[Develop fix in developer sandbox]
    D --> E[Test in partial or full sandbox]
    E --> F[Approval and change window]
    F --> G[Deploy to production]
    G --> H[Monitor and verify]
    H --> I[Propagate to other environments]
    I --> J[Close hotfix and update documentation]

4) Integrate a production change into alm

flowchart TD
    A[Change made in production] --> B[Capture metadata]
    B --> C[Commit to version control]
    C --> D[Replicate in sandbox]
    D --> E[Run tests and validation]
    E --> F[Update pipelines and scripts]
    F --> G[Train users if needed]
    G --> H[Track in release notes]

5) Multi org artifact management choices

flowchart TD
    A[Need to share artifacts across orgs] --> B[Source driven with git]
    A --> C[Metadata api retrieve and deploy]
    A --> D[Package based deployment]
    A --> E[Change sets]
    B --> F[Automate with ci cd]
    C --> G[Use package xml and zip]
    D --> H[Use unlocked or managed or unmanaged]
    E --> I[Use for small connected org moves]

6) Compliance and risk gate before production change

flowchart TD
    A[Proposed production change] --> B[Classify risk and data sensitivity]
    B --> C[Security and privacy review]
    C --> D[Select change window]
    D --> E[Notify support and business]
    E --> F[Prepare rollback plan]
    F --> G[Proceed or defer to sandbox]

7) Low risk config change in production

flowchart TD
    A[Request new field or picklist value] --> B[Check page layouts and reports]
    B --> C[Confirm no automation impact]
    C --> D[Apply change in production]
    D --> E[Smoke test with sample users]
    E --> F[Announce and update help text]
    F --> G[Sync change to sandboxes]

8) Daily metadata drift control

flowchart TD
    A[Schedule metadata export] --> B[Commit to version control]
    B --> C[Diff against main branch]
    C --> D[Publish changes to team]
    D --> E[Refresh affected sandboxes]
    E --> F[Align tests and pipelines]

📚 Flashcards

⚡ Direct Changes in Production

What are direct changes in production?

Directly editing live Salesforce org configuration or metadata without going through sandbox → used only for low-risk, urgent fixes.

When to use sandbox instead

Use sandboxes for coding changes or high-impact changes (e.g. new workflows, global features) to avoid disrupting business.

Key risks

• Errors from skipping tests
• Conflicts with other updates
• Compliance / regulatory violations

❓ When should you avoid making direct changes in production?

When the change is high-impact or code-related, such as new workflows, triggers, or global features → use a sandbox instead.

❓ What are the main risks of making direct changes in production?

• Errors from skipping testing

• Conflicts with other updates or integrations

• Compliance and regulatory violations

❓ What are examples of low-risk changes that may be made directly in production?

Adding picklist values, reports, dashboards, or other small configuration changes — after double-checking and communication.

---

🧩 Safe Practices for Direct Changes

Safety checklist

• Double-check impact and dependencies

• Get stakeholder approval

• Communicate clearly to users

• Release in phases with super-user validation

• Train affected users after the change

Strategies

• Create a hotfix process for urgent changes

• Require review & authorization

• Use release management tools to plan and track

❓ What steps ensure safe direct changes in production?

• Double-check dependencies

• Get stakeholder approval

• Communicate changes to users

• Validate in phases

• Provide user training

❓ What strategies help manage urgent fixes directly in production?

• Establish a hotfix process

• Require review and authorization

• Use release management tools to plan and track

---

⚙️ Integrating Changes into ALM

Why it matters

Direct production changes skip the normal lifecycle, so they must be incorporated back into ALM to keep orgs and version control in sync.

How to integrate

1. Capture metadata from production

2. Commit to version control

3. Recreate in sandbox

4. Validate with tests

5. Sync into pipelines and scripts

6. Document in release notes

❓ Why must direct changes be integrated back into ALM?

To keep version control and lower environments in sync and prevent inconsistencies.

❓ How do you integrate a direct production change into ALM?

1. Capture metadata from production

2. Commit to version control

3. Recreate in a sandbox

4. Validate with tests

5. Include in pipelines and documentation

---

📡 Communication, Training & Monitoring

Communication

• Announce planned production changes

• Explain purpose, timing, and impact

Training

• Brief affected users

• Provide guidance on using new changes

Monitoring & coordination

• Watch for side effects or errors

• Adjust as needed

• Coordinate with sandbox refresh cycles to keep environments aligned

❓ Why is communication crucial for direct changes?

So users are not surprised and understand the purpose, timing, and impact of the change.

❓ What should be done after direct changes are deployed?

• Brief/train affected users

• Monitor for issues

• Adjust or roll back if problems arise

---

🧠 Multi-Org Artifact Management

Why challenging

Multiple Salesforce orgs must stay consistent with shared artifacts (fields, classes, components).

Main approaches

• Source-driven dev (Git as source of truth + CI/CD)

• Metadata API (retrieve() / deploy() + package.xml)

• Packages (managed, unmanaged, unlocked)

• Change Sets (simple, only between related orgs)

Special considerations

• Document all components with RTM

• Evaluate 3rd-party tools for rollback, backup, and recovery

❓ What is the main challenge of multi-org environments?

Keeping shared artifacts (fields, classes, components) consistent across orgs.

❓ What are the 4 main approaches to manage common release artifacts?

• Source-driven development (Git + CI/CD)

• Metadata API (retrieve/deploy with package.xml)

• Packages (managed, unmanaged, unlocked)

• Change Sets (simple, connected orgs only)

❓ What extra practices help?

• Maintain a Requirements Traceability Matrix (RTM)

• Evaluate 3rd-party tools for rollback, backup, and recovery

---

📍 Business Scenario Reminders

Critical bug in production

• Create hotfix branch

• Fix in sandbox → test → deploy

• Get stakeholder approval (for compliance)

• Sync back to source control

Metadata drift from direct changes

• Commit daily metadata backup to VCS

• Publish differences

• Refresh developer sandboxes after production changes

No access to production

• Developer retrieves metadata via Metadata API → creates .zip with package.xml → sends to release team

• Release team validates and deploys with Salesforce CLI

❓ What steps should be taken for a critical bug in production?

• Create a hotfix branch

• Fix → test in sandbox → deploy

• Get stakeholder approval

• Sync to source control

❓ How to handle metadata drift from direct production changes?

• Commit daily metadata backup to VCS

• Publish differences

• Refresh dev sandboxes

❓ How to deploy if consultant has no access to production?

• Consultant: retrieve metadata using Metadata API → make .zip with package.xml

• Release team: validate (project deploy validate) → deploy (project deploy quick)