US companies run Salesforce managed services with a delivery team in India by agreeing three things up front: which US hours the team covers and how, who in the US directs priorities, and how Salesforce's own access controls limit what each offshore person can see and change. With those in writing, the time difference becomes a planning detail rather than a risk.
This guide covers how coverage works across US and India hours, how to govern the service, the Salesforce features that control access, what to put in the contract and how to evaluate a provider. For what a managed services contract usually includes, see Salesforce managed services.
What is the time difference between the US and India?
India Standard Time (IST) is UTC+5:30, and India does not use daylight saving time. US time zones move by an hour when US daylight saving starts in March and ends in November, so the gap to India changes twice a year.
| US time zone | India is ahead by (US daylight time) | India is ahead by (US standard time) | 9:00 a.m. US standard time is, in India |
|---|---|---|---|
| Eastern | 9 h 30 min | 10 h 30 min | 7:30 p.m. |
| Central | 10 h 30 min | 11 h 30 min | 8:30 p.m. |
| Mountain | 11 h 30 min | 12 h 30 min | 9:30 p.m. |
| Pacific | 12 h 30 min | 13 h 30 min | 10:30 p.m. |
In practice, a normal India working day falls during the US night. That is an advantage for work that can run while US users are offline, and a constraint for requests that need an answer during the US day.
How can an India-based team cover US business hours?
There are three common coverage models, and many contracts mix them. The right one depends on how much of your Salesforce work is urgent during the US day and how much can be planned.
| Model | How it works | Suits | Watch for |
|---|---|---|---|
| Overlap shift | Some of the India team work a later shift that overlaps the US morning | Teams that need live answers during part of the US day | Which US hours are covered live, and which are not |
| Follow the sun | Requests raised in the US day are worked overnight in India and ready by the next US morning | Planned enhancements, fixes, testing and release preparation | A clear handoff note at the end of each day on both sides |
| US lead, India team | A US-based lead or your own admin handles live requests; the India team does the build and run work | Orgs with many users who expect same-day contact | Who decides priorities when the lead is out |
Whatever the model, write down the hours of coverage in a named US time zone, how urgent issues are raised outside those hours, and the response targets for each priority. Do not assume "24/7" means the same thing to both sides.
Time-shifted work helps with Salesforce releases. Salesforce ships three major releases a year, and sandbox preview instances are upgraded weeks before each release, according to Salesforce Help. A team working during the US night can run regression tests in the preview sandbox without disturbing users.
How should the service be governed?
Governance answers who sets priorities, who approves changes and how you know what was done. Keep it simple and regular. The most common failure in offshore managed services is not skill but unclear ownership on the client side.
- A US product owner. One person on your side owns the backlog and decides priorities.
- A named delivery lead. One person on the provider side owns the service and is your first contact.
- A shared queue. All requests go through one ticketing or backlog tool that both sides can see.
- A change process. Changes are built and tested in a sandbox, approved by your owner and deployed through an agreed release path, never edited directly in production.
- A regular rhythm. A short weekly call for open items and a monthly review of work done, hours used and what comes next.
- Documentation. Runbooks, a configuration record and handoff notes kept where you can read them.
Which Salesforce controls limit what an offshore team can access?
Salesforce has built-in controls that let you give each team member only the access their role needs and restrict where and when they can log in. These are configured in your org, so you can check them yourself.
| Control | What it does | How to use it for an offshore team |
|---|---|---|
| Profiles, permission sets and permission set groups | Grant access to objects, fields and features. Salesforce Help notes they grant access but cannot deny it | Start each person with minimal access and add only what their role needs; review it regularly |
| Login IP ranges on a profile | Once a profile has a range, logins from any other IP address are denied | Limit the support team's profile to the provider's office or VPN addresses |
| Enforce login IP ranges on every request | A session setting that checks profile IP ranges on each request, not only at login | Consider it where support users must stay on approved networks throughout a session |
| Trusted IP ranges | Let users from listed addresses skip the login challenge; users outside them can still log in after verifying | Do not treat them as a block; use profile login IP ranges for that |
| Login hours on a profile | Restrict the hours when users on that profile can log in, read in the org's default time zone | Set hours that match the agreed coverage, allowing for the time difference |
| Setup Audit Trail | Shows the 20 most recent setup changes, with a download of the last 180 days | Review configuration changes each month, or download them for your records |
Sources: Salesforce Help on login IP ranges, trusted IP ranges, session settings, permissions and access and Setup Audit Trail, and the Trailhead project on login hours, which has you check the org's default time zone before setting them.
Give every person their own named user. Shared logins make the audit trail meaningless. Remove or freeze access on the day someone leaves the team, and make that a written step in the contract.
When does Salesforce Shield come into it?
Salesforce Shield is a paid add-on for protection beyond the platform's built-in security. Salesforce lists four components: Platform Encryption for fields and files at rest, Event Monitoring for user activity such as logins and report exports, Field Audit Trail for longer field history, and Data Detect to find sensitive data in your org. Components can also be bought separately.
Whether you need Shield depends on the data in your org and your compliance obligations, not on where your support team is based. If you already have it, ask the provider how they will work with it, for example which Event Monitoring data you will review together. If you do not, decide with your security team and your Salesforce account team.
What should you put in the contract?
The contract should turn the coverage model, governance and access rules above into commitments both sides can check. These are the clauses US buyers most often need.
- Scope: the request types covered, such as admin support, fixes, enhancements, release testing and monitoring, and what is excluded.
- Coverage: hours in a named US time zone, how out-of-hours issues are raised, and response targets by priority.
- Allowance: the monthly hours or services and what happens to unused or extra hours.
- People: named key roles, notice of changes and a replacement process.
- Access: named users only, least-privilege access, IP and login restrictions, and same-day removal when someone leaves.
- Data handling: where work is done, whether production data may be copied to sandboxes, and how it is masked or removed.
- Releases: how each Salesforce release is reviewed and tested before it reaches production.
- Reporting: what the monthly report contains.
- Exit: a handover plan, documentation you keep and the notice period.
- Legal terms: confidentiality, intellectual property, governing law and liability, reviewed by your counsel.
How do you evaluate an offshore Salesforce managed services provider?
Judge the provider on how it will run your org, not on headcount or slogans. Ask each one the same questions and compare the answers in writing.
- Check the listing. Confirm the partner tier, rating and reviews on AppExchange yourself.
- Meet the team. Speak to the delivery lead and core members, and check their certifications on Trailhead.
- Ask for the coverage plan. Which US hours are covered live, by whom, and how urgent issues are handled outside them.
- Ask for the access model. Which profiles and permission sets the team will use, and how access is granted and removed.
- Ask how they handle a release. A clear answer names the sandbox preview, the tests run and who signs off.
- Ask for a sample monthly report. It shows what you will actually see each month.
- Ask for a US reference. Speak to a US client about communication across time zones.
Techila Global Services is a Salesforce Summit partner, headquartered in Frisco, Texas, with its main delivery centre in Pune, India. We expect you to ask us every question above.
Frequently asked questions
What is the time difference between India and the US for a Salesforce support team?
India Standard Time is UTC+5:30 and India does not use daylight saving time. India is 9.5 hours ahead of US Eastern time in summer and 10.5 hours ahead in winter, and 12.5 or 13.5 hours ahead of US Pacific time. 9:00 a.m. Central Standard Time is 8:30 p.m. in India.
Can a team in India cover US business hours?
Yes, if the contract says so. Common patterns are a shift in India that overlaps the US morning, a follow-the-sun model where US requests are worked overnight in India, or a US-based lead with the India team behind them. Agree the hours of coverage and the response targets in writing.
How do we control what an offshore team can access in Salesforce?
With standard Salesforce controls: profiles, permission sets and permission set groups to grant only the access each person needs, login IP ranges on profiles to block logins from other addresses, login hours, and Setup Audit Trail to review configuration changes. Remove access the day someone leaves the team.
Do we need Salesforce Shield for offshore managed services?
Not necessarily. Shield is a paid add-on that includes Platform Encryption, Event Monitoring, Field Audit Trail and Data Detect. Whether you need it depends on your data and your compliance requirements, not on where your support team sits. Ask your security team and Salesforce account team before you decide.
What should a US company put in an offshore managed services contract?
The scope of services, hours of coverage in a named US time zone, response targets by priority, named roles, the access model and how access is removed, where work is done, data handling rules, reporting, the process for Salesforce releases, a handover plan for exit, and which country's law governs the contract.
Next steps
To work out a coverage model and access plan for your org, book a discovery call. For the wider choice between models, see staff augmentation vs outsourcing vs managed services.