A Salesforce contractor can start adding value on day one, or spend the first week waiting for access and asking who approves what. The difference usually comes down to what the hiring team confirmed before the start date. Salesforce contractor onboarding covers the contract terms, the user setup, the security controls and the working rules that let a consultant or developer get to work safely.
The stakes rose in 2026. Salesforce began enforcing multi-factor authentication for all employee (internal) users, with stricter rules for anyone holding powerful permissions. At the same time, a series of data theft campaigns showed how attackers abuse connected apps and bulk data tools. This Salesforce contractor onboarding checklist explains what to confirm before a contractor logs in, why each item matters now and who should own it.
TL;DR
• Settle the contract items first, including code ownership and confidentiality, before any user is created.
• Verify the contractor’s identity, since federal agencies warn that contract IT roles are a target for fraud.
• Give each contractor a named user and a role-based permission set group with only the access they need.
• Confirm MFA before day one, especially if the contractor needs admin-level or developer permissions.
• Decide sandbox access and app approval rules in advance so nobody improvises on day one.
What Salesforce contractor onboarding covers
Salesforce contractor onboarding is the set of steps that turn a signed contractor into a working, properly secured Salesforce user. It starts before any technical setup, with the legal and identity checks that decide whether the person should have access at all. It ends when the contractor can log in and follow your release process without asking for exceptions.
The work usually spans several teams. Procurement or legal handles the contract. HR or security handles identity checks. The Salesforce admin team creates the user and assigns access. The project lead explains the working rules. When these teams don’t coordinate, the contractor arrives to find half the steps done and the rest waiting on someone who didn’t know they were needed.
Contractors differ from employees in ways that matter for Salesforce. They’re often brought in for a specific build, such as a new integration or a Service Cloud rollout, and they may need powerful permissions for a short time. They may also work for several clients and leave on a fixed end date. A good onboarding process plans for all of that before day one.
A repeatable process also saves money. Every day a contractor spends waiting for access is a day you pay for without progress. When Salesforce contractor onboarding follows the same steps each time, admins stop rebuilding access from scratch and contractors know what to expect before they start.
This guide focuses on what to confirm before the start date. Some items, such as audit trail reviews, continue during the engagement. They’re included because the setup decisions that make them possible have to happen first.
Why day-one readiness matters more in 2026
Two changes have made careful Salesforce contractor onboarding more important than it was a year or two ago. The first is MFA enforcement. The second is a run of attacks that targeted exactly the kind of access contractors often receive.
MFA is now enforced
Salesforce has required multi-factor authentication contractually since 2022, but it now enforces it in the platform. Salesforce paused and rescheduled the 2026 rollout, and production enforcement for employee users began on July 20, 2026, with timing that varies by release group. The Salesforce Admins team explained in its MFA enforcement guide that phishing-resistant MFA also applies to privileged users, including anyone with the Modify All Data, View All Data, Customize Application or Author Apex permissions. That privileged-user rollout extended across release groups into September 2026, so check Salesforce Help for the dates that apply to your instance.
That privileged list matters for contractors. Developers and technical consultants often need Customize Application or Author Apex, at least in a sandbox. A contractor who hasn’t set up an accepted phishing-resistant method may not be able to log in with those permissions, which turns a routine start into a blocked one.
Attackers targeted connected apps and data tools
The second change is the threat picture. The FBI’s September 2025 Salesforce threat alert described a group that used voice phishing calls to guide victims to Salesforce’s connected app setup page and approve a modified version of Data Loader. The FBI noted that a malicious connected app can bypass defenses such as MFA and login monitoring, because the OAuth tokens come from Salesforce itself.
A second group used stolen OAuth tokens from the Salesloft Drift integration. Google’s threat intelligence team reported in its Drift incident analysis that the actor targeted Salesforce customer instances from August 8 to August 18, 2025. On August 20, Salesloft and Salesforce revoked all active access and refresh tokens for the Drift application.
These campaigns didn’t depend on contractors. They do show that app authorization rights and bulk data tools are high-value targets. Contractors often ask for exactly those rights, so the decisions about them belong in onboarding, not in a rushed conversation on the first morning.
Contract and legal items to confirm
The first part of Salesforce contractor onboarding happens before anyone touches Setup. In Salesforce contractor onboarding, the legal work sets the limits for everything that follows. Confirm these contract items in writing, because they decide who owns the work and what the contractor is allowed to do.
Confirm contractors are allowed users
Start with your Salesforce agreement. The standard Salesforce master agreement defines users as individuals the customer authorizes to use a service and has supplied with login credentials. It says users may include employees, consultants and contractors of the customer. The same agreement says the customer won’t make a service available to anyone other than the customer or its users. In practice, that means each contractor needs their own authorized user, set up under your license count.
If your organization has a negotiated agreement, check its version of these clauses. Some agreements add conditions, such as requiring contractors to be bound by confidentiality terms at least as strict as the customer’s own.
Settle code and configuration ownership
Ownership of the work needs a clear written answer. The US Copyright Office explains in its guide to works made for hire that a work created by an independent contractor counts as made for hire only in specific categories, and only with a written agreement. Software isn’t one of those categories. For Apex code and other custom work built by an independent contractor, companies usually need a written assignment of rights to own the result.
Confirm the assignment is signed before the contractor starts building. Also confirm how any reusable tools the contractor brings will be licensed to you, so there’s no dispute about what you can keep using after the engagement ends.
Check confidentiality and classification
Confidentiality terms should cover customer data in Salesforce, not only your business plans. A contractor may see personal data in production or a full copy sandbox, so the agreement should state how that data can be used and when access ends.
Worker classification also deserves a quick check. The Department of Labor’s proposed contractor rule from February 2026 focuses on control over the work and the worker’s opportunity for profit or loss. If the “contractor” will work set hours under daily direction like an employee, review the arrangement with counsel before onboarding continues.
Identity checks before the user is created
Confirm who the contractor is before you create their Salesforce user. This step used to be a formality. It now carries real security weight.
Federal agencies have warned that contract IT work is a common path for fraudulent remote workers. In July 2025 guidance, the FBI recommended in-person meetings where possible and, for virtual meetings, requiring video with an unobscured background. It also suggested asking the person to wave a hand in front of their face, since that can disrupt AI-generated video. A joint alert from the State Department and allied governments in July 2026 said these workers obtain work through online platforms for employment and contracting of services, often using identity documents supplied by proxies.
For Salesforce roles, the risk is concrete. A contractor with admin or developer access can export data and change security settings. The FBI’s January 2025 data extortion alert warns that fraudulent IT workers may harvest credentials and session cookies to work from non-company devices, and often log in from IP addresses in several countries within a short period.
Before day one, confirm these points:
• The person you interviewed matches the identity documents and the name on the contract.
• The email address for the Salesforce user belongs to that person or their registered business.
• If the contractor comes through an agency, the agency has confirmed the assigned person is the one you interviewed.
• Payment goes to an account in the contractor’s name or their company’s name.
Record the checks in the onboarding file. If questions come up later, a clear record made at the start shows what was verified and when.
Licenses and user records
Every Salesforce contractor needs a named user of their own. Shared logins break audit trails and usually conflict with your Salesforce agreement.
Confirm the license type before the start date. A developer who builds in sandboxes and deploys through a release process may need a full Salesforce license in production, or may need none there at all if production changes go through a pipeline run by your team. A consultant who configures Service Cloud may need a license that matches the features they’ll set up. Getting this wrong can mean either paying for more than the role requires or blocking the contractor from the features they’re there to build.
Check license availability early as well. If every license in your org is assigned, you may need to buy one or free one up by deactivating a former user, and procurement can take longer than expected. Confirming the count 2 weeks ahead avoids a contractor arriving with no license to assign, which is one of the most avoidable day-one delays.
Set up the user record consistently. Use a naming convention that marks the user as a contractor, such as a suffix or a custom field, so they’re easy to find in reports. Record the contract end date in a place your admin team reviews regularly. Salesforce’s standard user record doesn’t end access on its own, so the end date needs a reminder or a process attached to it.
Plan the exit now. Decide who will freeze or deactivate the user when the contract ends and what happens to records the contractor owns. Salesforce’s standard agreements have long allowed a user login to be reassigned to a new person who replaces one who no longer needs access, which lets you reuse the license. The contractor’s own login, though, should never be handed to someone else.
Finally, match the user to your single sign-on setup if you use one. Decide whether the contractor will log in through your identity provider or directly to Salesforce. That choice affects how MFA is enforced and how quickly you can remove access at the end.
Access design with permission set groups
Decide exactly what the contractor can see and do before you create their user. The goal is least privilege, which NIST defines in its security glossary as giving each user only the minimum access needed to perform their tasks.
In Salesforce, the cleanest way to do this is with permission set groups. Build a group for each contractor role, such as “Contract Developer” or “Contract Service Cloud Consultant,” that bundles the permission sets the role needs. Assign the bundle, not a list of individual permissions. That makes access consistent across contractors and easy to remove when the engagement ends.
Separate build access from production access
Most contractors don’t need powerful rights in production. A developer can often build and test in a sandbox with Author Apex and Customize Application, then hand changes to your team to deploy. In production, the same person might need only read access to check results, or no access at all.
Give powerful permissions only in the environments where they’re needed. The Salesforce Admins team suggests using MFA preparation as a moment to ask whether users really need their higher-level permissions. For contractors, that question is easy to answer in advance, because the scope of work defines what they’ll do.
Watch the highest-risk permissions
Some permissions deserve extra scrutiny for any contractor:
| Permission | Why It Matters for Contractors | Typical Contractor Need |
| Modify All Data | Lets the user change any record in the org | Rarely needed, especially in production |
| View All Data | Lets the user read every record | Rarely needed outside a masked sandbox |
| Customize Application | Allows configuration changes | Often needed in a sandbox |
| Author Apex | Allows writing and changing code | Often needed in a developer sandbox |
| API Enabled | Allows access through tools like Data Loader | Grant only if the scope requires it |
The first 4 permissions also trigger the phishing-resistant MFA requirement. Every permission you remove from a contractor’s production access shrinks both the security risk and the setup work. Salesforce contractor onboarding goes faster when these groups already exist, because the admin only has to assign 1 bundle. Write the approved groups into the onboarding ticket, and have someone other than the requesting manager approve anything on the high-risk list.
MFA and login readiness
Confirm that the contractor can pass Salesforce MFA before their first working day, whichever tier applies to them. Under the 2026 enforcement, a user who can’t complete MFA can’t log in.
Start by checking which level of MFA applies. Standard Salesforce MFA applies to all internal users, and verification methods include authenticator apps and security keys. Phishing-resistant MFA applies to privileged users, including anyone with the 4 high-risk permissions listed above. If your permission set group for a contractor includes Customize Application or Author Apex, even in a sandbox, plan for the stricter requirement.
Check whether the contractor has an accepted phishing-resistant method, such as a hardware security key or a built-in device authenticator. Salesforce Help lists the accepted methods, and they can change, so confirm the current list before you send instructions. If your company issues security keys, ship one to the contractor’s verified address in time for day one.
If you use single sign-on, confirm that your identity provider sends an MFA signal Salesforce accepts. Salesforce has said its enforcement covers SSO logins as well as direct logins, so a gap in your identity provider setup can block contractors the same way.
Planning for contractors on their own devices
Many contractors work on their own laptops and phones. That affects Salesforce MFA in practical ways. An authenticator app on a personal phone works for standard users, but privileged users need a phishing-resistant method, which may mean a security key your company provides. Decide who supplies the key, how it’s registered and what happens if it’s lost.
Device rules also matter for security. If your policy requires company-managed devices for Salesforce access, confirm the contractor has one before day one. If you allow personal devices, write down the minimum requirements, such as an up-to-date operating system and screen lock. Salesforce MFA protects the login, but it doesn’t protect data once it’s on an unmanaged laptop.
Run a test login before the start date. Ask the contractor to log in to the sandbox they’ll use and complete Salesforce MFA registration. A 15-minute test the week before saves hours on the first morning.
Finally, brief the contractor on how your admins will contact them. The 2025 attacks relied on callers posing as IT support. Tell every new contractor that your team will never ask them by phone to approve an app or read out a code. That short message removes the easiest path attackers have used.
Sandbox and data access rules
Decide which environments the contractor will use and what data they’ll see there. Many teams give contractors a Salesforce sandbox and assume that means the data is safe. That’s only true if the sandbox has been prepared.
Full copy and partial copy sandboxes contain real production data. A contractor working in one can see customer names and case notes unless that data has been masked. Salesforce’s Data Mask tool is designed for this. It masks sensitive customer information in full or partial copy sandboxes so admins and developers can test with realistic data. Note that the Data Mask managed package requires an add-on license, so not every org has it. Salesforce also documents built-in masking options for sandboxes, so check which approach your org has access to before you plan the refresh.
The masking options vary by field. Salesforce’s Data Mask training explains that you can replace sensitive values with random characters, replace them with realistic values from built-in libraries or delete them. It also warns that deleted sandbox data can’t be restored, although production data isn’t affected. Choose the method based on what the contractor needs to test.
Match the sandbox to the work
A developer building new features often needs only a developer sandbox with test data, not a copy of production. A consultant testing a data migration may need a partial copy sandbox with realistic records, which should be masked first. Decide this before day one so the right Salesforce sandbox is refreshed and masked.
Confirm a few more details as well. Which sandbox is the contractor’s primary workspace? Who can refresh it? Can the contractor export data from it, and if so, where can that data go? Write the answers into the onboarding notes so the contractor knows the rules from the start.
Timing matters too. A Salesforce sandbox refresh can take hours or longer, depending on the sandbox type and data volume, and masking adds more time. Schedule the refresh early enough that the Salesforce sandbox is ready before the contractor’s first login. Name it clearly, so the contractor doesn’t confuse it with another team’s Salesforce sandbox, and record its refresh date in the onboarding notes.
If the contractor must work in production, keep the time and scope narrow. Give production access only for the tasks that require it, and review it at set points during the engagement.
Connected apps and API access
Decide your app approval rules before a contractor asks to install a tool. Contractors often bring their own utilities, such as Data Loader or deployment tools that connect through OAuth. Each of those connections creates a token with access to your org.
The 2025 attacks showed how this can go wrong. In one route, attackers talked employees through Salesforce’s OAuth consent screen to approve a fake Data Loader. In another, they stole tokens from a third-party vendor whose app already had access. A Hacker News report on Microsoft’s analysis of these campaigns noted that Microsoft’s guidance matched what vendors said after each incident. It recommended turning on and actually watching Salesforce event logs, along with locking down Experience Cloud guest-user access.
For contractor onboarding, that leads to a few clear rules:
1. Confirm who in your org can approve new OAuth apps, and make sure contractors aren’t on that list unless the role truly requires it.
2. List the tools the contractor needs, such as Data Loader or a specific deployment tool, and approve each one before day one.
3. Grant API Enabled only if the scope needs it, and prefer granting it in a sandbox over production.
4. Tell the contractor which apps are already approved, so they don’t try to authorize new ones.
5. Plan to review the contractor’s app authorizations at the end of the engagement and revoke any tokens they created.
Apply the same rules in every Salesforce sandbox. A connected app approved in a sandbox still receives tokens that can read whatever data that sandbox holds, and a full copy sandbox that hasn’t been masked holds real customer records. Review connected app approvals in sandboxes as carefully as in production, and remove any that were only needed for a finished task.
These rules also help honest contractors. When they know which tools are approved and how to request others, they don’t have to guess, and your team doesn’t have to clean up unexpected connections later.
Change management and audit trail expectations
Agree on how the contractor’s changes will reach production before they start building. Unclear release rules are one of the most common causes of friction with Salesforce contractors.
Start with the path to production. Will the contractor deploy directly, or hand changes to your team through source control and a release pipeline? Who reviews and approves each change? What testing is required first? If your team uses a specific tool or branching model, give the contractor access to it on day one along with the Salesforce sandbox.
Set expectations for documentation too. Ask contractors to describe each change in the ticket or pull request, including which objects and permission sets it touches. That record helps your team support the work after the contract ends.
Know what the audit trail captures
Salesforce records configuration changes automatically. The SetupAuditTrail object represents changes made in your org’s Setup area for at least the last 180 days. That covers many of the changes a contractor might make, such as edits to permission sets and users.
The retention window matters for contract work. If an engagement runs longer than about 6 months, or if you need records for an audit later, export the Setup Audit Trail regularly. Record-level data changes aren’t in the Setup Audit Trail, so decide whether you need field history tracking or event monitoring for the objects the contractor will work on.
Plan the handover as part of the same conversation. Before day one, agree on what documentation the contractor will leave behind, such as a summary of the custom objects and integrations they built. Contractors who know the handover standard from the start write better notes as they go, which is far easier than reconstructing decisions in the final week of the contract.
Tell the contractor that these records exist and that your team reviews them. It sets a clear expectation, and it lets you spot surprises early, such as a permission change nobody requested.
A day-one Salesforce contractor onboarding checklist by owner
The table below pulls the checklist together by owner and timing. Use it as a template for your own Salesforce contractor onboarding tickets, adjusting owners to match your team structure.
| Item to Confirm | Owner | When |
| Contract signed with IP assignment and confidentiality terms | Legal or procurement | 2 weeks before start |
| Identity verified and matched to the contract | HR or security | 2 weeks before start |
| License type and user naming convention agreed | Salesforce admin | 1 week before start |
| Permission set group built and approved | Salesforce admin and project lead | 1 week before start |
| MFA method confirmed, including phishing-resistant keys if needed | Salesforce admin and IT | 1 week before start |
| Sandbox refreshed and masked | Salesforce admin | 3 days before start |
| Approved tools and OAuth apps listed | Salesforce admin and security | 3 days before start |
| Release process and source control access set up | Project lead | 3 days before start |
| Test login completed in the assigned sandbox | Contractor and admin | 1 to 2 days before start |
| Security briefing on vishing and approval requests | Security or project lead | Day one |
| End date recorded with an offboarding owner | Salesforce admin | Day one |
The timing is a guide, not a rule. Some identity checks take longer, and security keys can take several days to ship. Start with the items that have the longest lead time, and don’t create the Salesforce user until the contract and identity items are done.
Final thoughts
Good Salesforce contractor onboarding means the contractor spends day one on the work you hired them for. That depends on decisions made in the weeks before: a signed contract with clear ownership, a verified identity, a role-based permission set group and a tested login that meets the new Salesforce MFA rules.
The 2025 attacks and the 2026 MFA enforcement make these steps more than good practice. Contractors often need the same powerful access that attackers target, so the rules for sandboxes and app approvals need to be set before they log in. Treat your Salesforce contractor onboarding checklist as a living template. Review it after each engagement, adjust it as Salesforce changes its security requirements and keep the offboarding step as carefully planned as the start.
Frequently asked questions
What should a Salesforce contractor onboarding checklist include?
It should cover contract and ownership terms, identity checks, the license and user record, a role-based permission set group, MFA readiness, sandbox and data rules, app approval rules and the release process.
Can contractors have their own Salesforce licenses?
Yes. Salesforce’s master agreement says users may include contractors and consultants of the customer. Each contractor needs their own authorized user under your license count.
Can a contractor share another user’s login?
No. Shared logins break audit trails and weaken MFA. Salesforce’s standard agreements have long said a user’s password can’t be shared with another individual.
Does the 2026 Salesforce MFA enforcement apply to contractors?
Yes. It applies to internal users, which includes contractors with standard user licenses. Contractors with privileged permissions also need phishing-resistant MFA.
Which permissions trigger phishing-resistant MFA?
Salesforce has listed Modify All Data, View All Data, Customize Application and Author Apex. Users with these permissions need a phishing-resistant method to log in.
What are permission set groups?
They’re bundles of permission sets that you assign as a single unit. Building a group for each contractor role makes access consistent and easy to remove at the end of the engagement.
Should contractors work in production?
Only when the task requires it. Most development and configuration can happen in a sandbox, with changes deployed by your team through a release process.
Is it safe to give contractors a full copy sandbox?
Only after sensitive data is masked. Full and partial copy sandboxes contain real production data, and masking tools, such as the Salesforce Data Mask add-on or built-in sandbox masking options, can replace or remove sensitive values first.
Why are connected apps a risk?
They receive OAuth tokens that can access your data. In 2025, attackers tricked users into approving a fake Data Loader and stole tokens from a third-party integration.
Should contractors be allowed to use Data Loader?
Only if the scope needs it. Approve the specific tool in advance, grant API access only where required and prefer sandbox access over production.
Who owns code a Salesforce contractor writes?
Usually not the client by default. Custom code from an independent contractor typically needs a written assignment of rights, so sign one before work begins.
How long does Salesforce keep the Setup Audit Trail?
The Setup Audit Trail covers configuration changes for at least the last 180 days. Export it regularly if an engagement runs longer or you need records for audits.
How far ahead should onboarding start?
About 2 weeks before the start date works for most teams. Contract and identity checks take the longest, and security keys may need time to ship.
What should a contractor be told on day one?
Explain the approved tools and how your team will contact them. Make clear that nobody will call asking them to approve an app or share an MFA code.
What happens to the contractor’s user when the contract ends?
Freeze or deactivate the user and revoke any app tokens, then transfer records they own. The license can be reassigned to a new user, but the login itself shouldn’t be shared.