Salesforce Managed Services Scope What’s Included, What’s Not, and Who Owns What

A Salesforce Managed Services Scope should answer three questions for every task: Is it included? Does it cost extra? Who owns the outcome? Clear answers help prevent disagreements when work moves between your team and a provider. They also make it easier to track requests, approve changes, and understand what the monthly fee covers.

This guide explains what to define across seven areas: administration, user support, development, releases, security, integrations, and reporting. Use it to review a proposal, compare providers, or clarify an agreement you already have. If you’re weighing outside support against another hire, your backlog can help show whether Managed Services or a New Salesforce Hire is the better fit.

Table of Contents

How Should You Define Each Scope Item?

Start with three labels for every task:

Included: Covered by the recurring fee and stated service levels.
Extra: Available, but quoted separately as a project or change request.
Yours: Retained by your company, even if a provider does part of the work.

Then name two people: the person who does the work and the person who owns the decision or result. A provider may build a permission set, while your security lead approves it. A provider may test a release, while your sales operations manager confirms that reports still work. Recording both roles makes responsibility clear.

What Should a Salesforce Managed Services Scope Include?

The exact scope depends on your org and agreement. Use these seven areas as a checklist, then mark each task as included, extra, or yours.

1. Administration

Owner question: Who handles the daily requests that keep users working?

Included: User setup and deactivation, profile and permission set changes, page layouts, fields, picklists, queues, list views, and routine data fixes.
Extra: A new data model, a major process redesign, or onboarding an entire business unit.
Yours: Setting access policies and priorities when requests compete.

2. User Support

Owner question: Where do users go when something breaks, and how soon will they hear back?

Included: Ticket intake, priority triage, how-to answers, troubleshooting, and monthly reports on ticket volume and age.
Extra: Formal training programs, new-hire courses, or support outside agreed hours.
Yours: Naming an internal contact who can make business decisions about requests.

Ask whether the provider will open and follow up on Salesforce Support cases when the issue sits with Salesforce. Vendor support and partner support work best when one person coordinates both.

3. Development

Owner question: When does a small change become a project?

Included: Flow fixes, small automations, minor Apex or Lightning component changes, validation rules, and bug fixes in existing code.
Extra: New custom apps, large Apex builds, new Agentforce use cases, or work that needs discovery before anyone can estimate it.
Yours: Keeping access to code, repositories, and technical documentation.

Set a threshold, such as the number of hours per request, above which work becomes a change request. Without one, a “small enhancement” can keep growing. Salesforce’s Premier Success Plan includes developer support for troubleshooting up to 200 lines of custom code. It does not replace development work or define who owns your code.

4. Releases and Deployments

Owner question: Who checks that platform updates and your own changes do not break key processes?

Salesforce Seasonal Releases

Salesforce delivers three major platform releases each year. Its release guidance recommends reviewing release information and testing your org in a sandbox. A preview sandbox is typically updated four to five weeks before production. Define whether your provider will review release notes, run tests, fix issues, and brief users.

Your Own Deployments

Define responsibility for sandbox management, regression testing, deployments, rollback plans, and release notes. Our Salesforce release management framework can help both sides agree on how to review and release changes.

Your team should keep the final go-or-no-go decision for changes that affect revenue, finance, or customers.

5. Security and Access

Owner question: Who checks access, and who decides which risks are acceptable?

Salesforce describes security as a shared responsibility between Salesforce and its customers. In a managed services arrangement, your provider may do hands-on work, but your organization should keep control of access policy, risk decisions, and compliance obligations. Start with Salesforce’s shared responsibility model.

Included: Periodic access reviews, permission cleanup, Security Health Check reviews, connected app reviews, and agreed follow-up work.
Extra: Setting up add-on security products such as Shield or Backup & Recover, or preparing for a formal audit.
Yours: Setting access policies, approving privileged access, meeting compliance duties, and making decisions during an incident.

Include the provider’s own logins in your access plan. Salesforce requires MFA for employee logins and has additional phishing-resistant MFA requirements for some privileged users. Check Salesforce’s current MFA guidance for privileged users. Your scope should say who provisions and removes provider access and how those accounts follow your security rules.

6. Integrations

Owner question: When data stops moving, who notices and who investigates?

Included: Error monitoring, failed-sync investigation, credential and certificate renewals, field mapping fixes, and small changes to existing integrations.
Extra: New integrations, replacing middleware, or redesigning how systems connect.
Yours: Managing the other system. If your ERP team changes an API, the Salesforce provider may need help from that team to resolve the issue.

For each integration, record where the provider’s responsibility ends and who to contact when the problem sits with another vendor or internal team.

7. Reporting and Data Quality

Owner question: Who keeps the numbers trustworthy?

Included: Report and dashboard changes, duplicate management, validation rule updates, and fixes for broken report logic.
Extra: Large cleanup projects, data migrations, and new analytics builds.
Yours: Defining business terms. Your team decides what counts as “qualified pipeline” or an “active customer.”

What Gray Areas Cause the Most Disputes?

Settle these questions before signing:

When is an enhancement too large? Set an hours threshold and describe the change-request process.
Who investigates problems caused by another system? A failed sync may involve your ERP, an AppExchange app, Salesforce, or the provider. Name who investigates first and who contacts each vendor.
Who supports Agentforce after launch? Salesforce’s Core, Advanced, and Max editions for certain Agentforce products include Flex Credits. Define who monitors usage, receives alerts, and decides what to do when usage approaches the available allocation. See Salesforce’s edition details.
Who handles data recovery? Define who restores deleted records, which backup they use, and the expected response time.
What counts as an after-hours emergency? Confirm whether critical coverage runs around the clock or only during business hours, and how it is billed.

Which Responsibilities Should Stay With Your Company?

Keep these decisions and assets under your control:

Business priorities and the budget behind them
Approval of privileged access and sensitive changes
Access to your data, code, documentation, and credentials
Compliance and regulatory accountability
Your contract with Salesforce

Keeping the Salesforce contract in your company’s name does not mean you must negotiate alone. At Valintry360, we’re a certified Salesforce partner and can act as a bridge between your business and Salesforce to help you get the best deal on licensing and services. Your company still owns the contract and the decisions tied to it.

What Are Red Flags in a Salesforce Managed Services Scope?

Review or challenge a proposal that includes:

“Unlimited support” without defining what support covers
One response time for every issue, with no priorities or examples
Release testing described as “best effort” or left out
No change-request process or hours threshold
Code and documentation stored only in the provider’s systems
Integrations listed as “supported” without naming them
Exit terms that omit the handover plan

How Can You Turn This Checklist Into a Scope?

List your actual work. Review three months of tickets and requests, then group each item by area.
Label every task. Mark it included, extra, or yours. Name who does the work and who owns the result.
Send the same scope to every provider. Quotes are easier to compare when each provider prices the same tasks.
Test the agreement with real scenarios. Ask each provider how they would handle a failed release, an integration outage, and a privileged-access request from your backlog.

Our team includes 100+ certified professionals who can help you define a Salesforce managed services scope that fits your org.

Conclusion: Give Every Task a Scope and an Owner

A useful Salesforce managed services scope names what is included, what costs extra, and what your company retains. Use the seven-area checklist to find gaps, settle gray areas before they become disputes, and keep business decisions under your control. Then put the final scope, response targets, and handover terms in writing.

Salesforce Managed Services Scope: What’s Included, What’s Not, and Who Owns What