Which deployment approach minimizes downtime when introducing a new Service Cloud console app?

• A. Configure in a sandbox and push via change-set to production for testing and training.
• B. Configure in a developer org and use an unmanaged package to deploy to production.
• C. Deploy the configured and tested app to production. Update the agent's profile to view the app and take away access to the old app.
• D. Deploy the configuration from a sandbox to production during the next Salesforce version update so the system only goes down once.

Answer: (C)

Minimizing downtime comes from a staged cutover where the new setup is already in production and users are switched to it by changing visibility, not by taking the system offline. Deploy the configured and tested console app to production, then update each agent’s profile to grant access to the new app and remove access to the old one. Since both apps exist in production, there’s no forced downtime—the transition happens by changing what users can see, so they naturally switch to the new experience without an outage.

Why this works best: it keeps a parallel setup ready in production, validates the new console first, and then flips the switch at the user level. The other approaches either rely on separate environments or packages with less controlled rollout, or they depend on a Salesforce version window, which can introduce longer, less predictable downtime.