Day Ops Guide for Salesforce Teams | SalesforceTutorial

Written by Prasanth Kumar Published on Updated on

Day ops is the daily work required to keep a Salesforce environment available, secure, supportable, and aligned with business processes. It combines request triage, incident response, user access administration, automation monitoring, data-quality checks, release coordination, and communication with sales, service, marketing, finance, security, and engineering teams.

The work is broader than administering fields and page layouts. A Salesforce operations team must understand why a request exists, what systems and users it affects, how the change will be tested, and how the team will detect or reverse a failure.

What Does Day Ops Mean in a Salesforce Team?

In a Salesforce context, day ops describes the operating model used to manage the platform after implementation. It covers both planned work and unplanned work:

  • Planned work: approved enhancements, deployments, permission changes, data maintenance, sandbox activities, technical-debt reduction, and release preparation.
  • Unplanned work: failed automation, integration interruptions, access problems, record-locking errors, incorrect routing, data defects, and urgent business requests.

A mature team does not process every request as an immediate configuration task. It records the request, assesses business impact, identifies dependencies, selects an implementation path, tests the result, documents the decision, and monitors the outcome.

Salesforce identifies application lifecycle management, observability, governance, testing, incident response, and release management as parts of a resilient operating model. The Salesforce Well-Architected guidance for resilient solutions provides a useful foundation for defining these practices.

What Is Included in a Day Ops Runbook?

A day ops runbook gives the team a repeatable sequence for reviewing platform health and processing incoming work. The exact checks depend on the org’s products, integrations, support hours, data volumes, and compliance obligations.

Operating area Daily question Typical evidence Expected output
Request queue Which requests require action today? Case, work item, service-management ticket, or backlog record Owner, priority, due date, and next action
Automation Did scheduled, batch, queueable, or flow processing fail? Apex Jobs, Paused and Failed Flow Interviews, email alerts, logs Resolved failure or documented escalation
Integrations Are external systems exchanging data as expected? Middleware dashboard, API logs, platform events, reconciliation reports Incident, retry, correction, or confirmed healthy state
Security Were sensitive permissions or settings changed? Setup Audit Trail, access review, login information Approved change or security investigation
Data quality Did duplicates, missing values, or routing exceptions increase? Reports, validation failures, duplicate jobs, reconciliation queries Correction plan and root-cause owner
Releases What is moving through development, test, and production? Source control, DevOps Center, test evidence, deployment records Release decision and deployment status
Incidents Are users blocked or business transactions affected? Support cases, monitoring alerts, Salesforce Trust information Impact statement, mitigation, updates, and review

Start with impact, not arrival time

A request submitted first is not automatically the highest priority. Teams should classify work using business impact, affected users, security exposure, revenue or service interruption, compliance deadlines, and availability of a workaround.

For example, a request to add a dashboard field may wait while the team investigates a record-triggered flow that prevents all service agents from closing Cases. The second issue affects an active process and has no practical workaround.

Separate incidents, requests, problems, and changes

Using one undifferentiated queue makes reporting and prioritization difficult. Classify work before assigning it:

  • An incident is an interruption or reduction in an expected service.
  • A service request asks for a standard action such as access, a report, or a supported configuration change.
  • A problem investigates the underlying cause of one or more incidents.
  • A change modifies configuration, metadata, code, data, an integration, or an operating procedure.

This distinction allows the team to measure recurring failures separately from enhancement demand.

How Should Day Ops Requests Be Prioritized?

A practical prioritization model uses impact and urgency rather than the job title of the requester. Define the rules before an incident occurs so that the team can apply them consistently.

Priority Example Salesforce condition Response approach
P1 Production is unavailable, a core process is stopped for most users, or a security incident is active Open an incident channel, assign an incident owner, limit changes, mitigate first, and provide timed updates
P2 A department cannot complete a key process, but other functions remain available Assign technical and business owners, identify a workaround, and schedule rapid remediation
P3 A limited group is affected or a non-critical function behaves incorrectly Add to the planned queue and resolve under the team’s service target
P4 Enhancement, report request, cosmetic change, or long-term improvement Review value, dependencies, effort, and release timing during backlog planning

Do not classify an untested production change as the default response to an urgent request. A rushed fix can expand the incident by introducing a second failure.

What Does an Ops Lead Do?

Ops lead responsibilities in Salesforce

An ops lead coordinates daily execution. The role usually owns intake quality, prioritization, assignment, incident coordination, release readiness, and communication between business and technical teams.

The ops lead does not need to perform every configuration change. The role should make sure that each item has:

  • A defined business outcome and affected process.
  • An accountable business owner and technical owner.
  • Acceptance criteria that can be tested.
  • A security and data-impact review.
  • A delivery path through development, testing, and production.
  • A rollback or mitigation plan when the change carries material risk.

In enterprise orgs, the ops lead also coordinates Salesforce administrators, developers, integration teams, data teams, release managers, service-desk staff, and system owners. Clear ownership matters because a visible Salesforce error can originate in middleware, identity management, a downstream ERP, or a data pipeline.

Questions an ops lead should ask before accepting work

  1. Which users and business transactions are affected?
  2. Is this a defect, an enhancement, an access request, or a training issue?
  3. What is the expected result, and how will the requester verify it?
  4. Which objects, automations, integrations, reports, and permission sets depend on the change?
  5. Does a supported workaround exist?
  6. Can the work follow the normal release path?
  7. What evidence must be retained for audit or compliance purposes?

What Does a Head of Ops Do?

Head of ops responsibilities in Salesforce

The head of ops owns the operating system rather than the individual ticket queue. This role sets governance, staffing, service targets, risk thresholds, change policies, platform ownership, budget priorities, and the roadmap for reducing operational failure.

Typical responsibilities include:

  • Defining which team owns each Salesforce product, org, integration, and business process.
  • Approving the production-access model and separation of duties.
  • Establishing release calendars, blackout periods, and emergency-change rules.
  • Reviewing platform health, incident trends, backlog age, deployment results, and technical debt.
  • Resolving priority conflicts between departments.
  • Funding monitoring, test automation, documentation, environments, and training.
  • Ensuring that business continuity plans cover Salesforce and connected services.

The head of ops should avoid becoming the approval point for every small request. The goal is to create policies that allow routine work to move safely while reserving leadership review for high-risk, cross-functional, or financially significant decisions.

Day ops workflow for an ops lead and head of ops managing Salesforce requests, incidents, and releases
A Salesforce operations model connects request intake, impact assessment, implementation, release control, monitoring, and communication.

How Should Salesforce Automation Be Monitored?

Automation failures can leave records partially processed, delay integrations, or block users. The day ops checklist should cover the automation types used in the org rather than relying on a single dashboard.

Review asynchronous Apex jobs

The following SOQL query can help an authorized operator review recent asynchronous Apex activity. Run it with a user that has the required object and administrative access. Do not expose job details to users who do not need operational access.

SELECT Id,
       ApexClass.Name,
       JobType,
       Status,
       NumberOfErrors,
       JobItemsProcessed,
       TotalJobItems,
       CreatedDate,
       CompletedDate,
       ExtendedStatus
FROM AsyncApexJob
WHERE CreatedDate = TODAY
ORDER BY CreatedDate DESC
LIMIT 200

Investigate jobs with a failed or aborted status and jobs whose error count is greater than zero. A completed Batch Apex parent job can still require review when individual records were rejected by application logic or external systems.

Review scheduled Apex

SELECT Id,
       CronJobDetail.Name,
       State,
       NextFireTime,
       PreviousFireTime,
       TimesTriggered
FROM CronTrigger
WHERE State != 'DELETED'
ORDER BY NextFireTime ASC
LIMIT 200

Use this query to identify unexpected scheduling states or missing future executions. Do not update system scheduling records directly. Correct the underlying schedule through supported Setup, Apex, or deployment procedures.

Monitor Flow failures

Review failed and paused flow interviews, error emails, and records affected by the automation. A flow failure should not be treated only as a technical error. Determine whether the transaction rolled back, whether external work already occurred, and whether affected records require replay or correction.

For guidance on choosing and governing record-triggered automation, see the Salesforce record-triggered automation decision guide. It recommends managing Flow and Apex metadata through a development lifecycle and source control.

How Should Access and Configuration Changes Be Controlled?

Production access should follow least-privilege principles. Give operators the permissions required for their assigned duties through permission sets or permission set groups rather than using broad profiles as a routine shortcut.

Day ops security checks should include:

  • New or modified permission assignments.
  • Changes to login controls, connected apps, named credentials, integration users, and authentication settings.
  • Unexpected changes to validation rules, flows, Apex, sharing configuration, or email settings.
  • Departed or transferred users who still hold elevated access.
  • Temporary access that has passed its approved end date.

The Salesforce Setup Audit Trail documentation describes how administrative and configuration changes can be reviewed to determine who changed a setting and when. Setup Audit Trail is different from field history tracking: the former records supported Setup changes, while the latter tracks configured changes to record fields.

Operational warning: Setup Audit Trail supports investigation, but it is not a replacement for source control, deployment records, peer review, or a change ticket. It tells the team that a supported Setup action occurred; it does not supply the full business reason, test evidence, or dependency analysis.

How Should Day Ops Handle Salesforce Releases?

Release control prevents production from becoming the team’s development environment. Changes should move through an agreed path that includes source control, review, validation, testing, deployment approval, and post-deployment checks.

  1. Define the work item. Record scope, acceptance criteria, dependencies, risk, and owner.
  2. Develop outside production. Use a suitable development environment and retrieve or track the relevant metadata.
  3. Review the change. Check security, naming, automation interactions, bulk behavior, and test impact.
  4. Test at the correct levels. Include unit, integration, regression, permission, and user-acceptance testing where applicable.
  5. Validate deployment. Confirm metadata dependencies, Apex tests, required data, and activation steps.
  6. Deploy during an approved window. Communicate user impact and assign release ownership.
  7. Run post-deployment checks. Test key transactions, integrations, scheduled work, permissions, and monitoring.
  8. Close with evidence. Record the outcome, exceptions, follow-up work, and rollback status.

Salesforce DevOps Center provides work items, environment management, source-control integration, and pipeline-based promotion for declarative and programmatic changes. See the official DevOps Center overview and DevOps Center GitHub setup guidance.

DevOps Center is generally available. Some related command-line capabilities can have separate availability terms; for example, Salesforce identifies the DevOps Center CLI plugin documentation as a Beta service. Check the current feature documentation before including a Beta tool in a required production process.

For related platform procedures, review the SalesforceTutorial guides to create and manage a Salesforce sandbox, understand Salesforce deployment methods, and configure Salesforce permission sets.

How Should an Ops Team Respond to an Incident?

An incident process should reduce impact before the team starts a full root-cause investigation. The following sequence works for many Salesforce incidents:

  1. Confirm the symptom. Record the error, time, user population, affected process, environment, and reproducible steps.
  2. Assess scope. Determine whether the problem affects one user, one profile, one region, one integration, or the whole org.
  3. Check recent changes. Review deployments, feature activations, permission updates, data loads, integration releases, and Setup Audit Trail.
  4. Assign roles. Name an incident owner, technical investigators, business contact, and communications owner.
  5. Mitigate safely. Pause the affected automation, disable a failing integration route, restore a previous version, or provide an approved workaround when appropriate.
  6. Validate recovery. Test the full business transaction, not only the screen that displayed the error.
  7. Reconcile data. Identify missing, duplicated, delayed, or partially processed records.
  8. Review the cause. Document why controls failed and which preventive action has an owner and due date.

Do not deactivate automation without checking dependent processes. Disabling a record-triggered flow may remove the visible error while silently stopping assignment, compliance, integration, or notification logic.

Which Metrics Should Day Ops Track?

Ticket volume alone does not show platform health. Use a balanced set of service, delivery, risk, and quality measures.

Metric What it reveals Common interpretation error
Incident count by service Where users experience repeated disruption Treating all incidents as equal regardless of impact
Mean time to acknowledge How quickly the team starts coordinated response Confusing acknowledgement with resolution
Mean time to restore How long affected service remains impaired Closing the incident before data reconciliation finishes
Change failure rate How often releases require rollback, hotfix, or incident response Excluding emergency corrections from the calculation
Backlog age Whether demand exceeds capacity or priorities remain unclear Using average age when a small set of old items is hidden
Automation failure trend Whether Flow, Apex, or integration reliability is declining Counting retries as permanent resolution
Access-review exceptions Where permissions exceed approved responsibilities Reviewing licenses without reviewing assigned permissions
Recurring problem rate Whether root causes are being removed Renaming duplicate incidents instead of linking them

The head of ops should review trends and systemic risks. The ops lead should use the same data to adjust daily assignments, escalation, and preventive work.

Best Practices for Salesforce Day Ops

  • Use one intake path. Requests hidden in direct messages and meetings are difficult to prioritize, audit, and measure.
  • Define service ownership. Every org, integration, automation domain, and critical business process needs an accountable owner.
  • Keep production changes traceable. Link each deployed change to a work item, source-control revision, approval, test result, and release record.
  • Protect preventive capacity. Reserve time for monitoring, documentation, test automation, technical debt, and recurring-problem removal.
  • Test permissions explicitly. A system administrator’s successful test does not prove that a sales representative or service agent has correct object, field, record, and Apex access.
  • Include integrations in change analysis. A renamed field, changed validation rule, altered picklist, or new required value can affect middleware and downstream systems.
  • Document manual steps. Data loads, activation sequences, scheduled jobs, certificate changes, and post-deployment actions need owners and verification evidence.
  • Review direct production changes. Emergency work should enter source control and the normal release record after service is restored.
  • Close the feedback loop. Use incident and request trends to improve training, architecture, intake forms, automated tests, and monitoring.

Common Day Ops Mistakes

Building before understanding the request

A request such as “make this field required” does not describe the business rule. The requirement may apply only to one record type, stage, product, region, or user group. Clarify the decision logic before selecting a validation rule, flow, page setting, or Apex implementation.

Giving every urgent request the same priority

Repeated escalation by senior stakeholders can displace incidents and compliance work. Publish the priority criteria and require an impact statement for expedited requests.

Allowing undocumented production administration

Direct changes create drift between production, source control, and development environments. When emergency work is necessary, document it and reconcile the metadata after recovery.

Measuring output without reliability

A large number of completed tickets can coexist with repeated incidents, fragile automation, excess permissions, and an aging backlog. Measure service outcomes and risk, not only task completion.

Ignoring data recovery after technical recovery

An integration can return to a healthy status while transactions remain missing or duplicated. Define how the team identifies the affected time window, reconciles records, replays safe operations, and receives business confirmation.

Frequently Asked Questions

What is day ops in Salesforce?

Day ops in Salesforce is the recurring work used to operate the platform after implementation. It includes request triage, incident response, access administration, automation monitoring, integration checks, data-quality work, release coordination, documentation, and communication with business teams.

What does an ops lead do each day?

An ops lead reviews incoming work, assigns priorities and owners, coordinates incidents, checks release readiness, removes blockers, and communicates operational status. The role also makes sure requests have acceptance criteria, dependency analysis, test evidence, and an approved production path.

What is the difference between an ops lead and a head of ops?

An ops lead coordinates daily execution, while a head of ops owns the wider operating model. The head of ops sets governance, staffing, risk thresholds, service targets, release policies, platform ownership, and improvement priorities.

Should Salesforce admins make urgent changes directly in production?

Direct production changes should be limited to approved emergency procedures. The team should assess impact, record authorization, identify rollback or mitigation steps, validate the result, and then reconcile the change with source control and the standard release process.

Which Salesforce jobs should day ops monitor?

The team should monitor the automation used by its org, including Batch Apex, Queueable Apex, scheduled Apex, platform-event processing, record-triggered flows, scheduled flows, integration jobs, and data pipelines. Monitoring should include business outcomes and data reconciliation, not only technical completion statuses.

Day Ops Operating Checklist

  • Review incidents, service requests, changes, and overdue work.
  • Confirm owners and priorities for items requiring action.
  • Check asynchronous Apex, scheduled work, Flow failures, and integration monitoring.
  • Review high-risk access and configuration changes.
  • Confirm today’s deployments, approvals, test evidence, and post-release checks.
  • Reconcile records affected by recent failures or retries.
  • Communicate material incidents, risks, decisions, and dependencies.
  • Record recurring problems and assign preventive actions.

Day ops becomes manageable when intake, ownership, release control, monitoring, and incident response follow known procedures. The ops lead keeps daily work moving; the head of ops makes sure the operating model can support business change without losing control of security, reliability, or maintainability.