Salesforce Admin: Contractor Access That Has to Expire

Contractor Access That Has to Expire

Northwind Field Services runs one org with 310 internal users and is onboarding 45 contractors for a five-month inspection project. Contractors must read Cases and edit a custom Inspection__c object, but must not export reports or see Accounts outside their region. The admin proposes cloning the Standard User profile into a Contractor profile with login hours of 07:00-19:00 and Case read-only. In review you find that every department profile was cloned from an older baseline that still grants Modify All Data on Cases, and an audit shows 12 internal users currently hold it. SSO is enforced for all users, and contractors sign in from unmanaged home networks.

1. How should contractor access be granted, and how does the platform guarantee it ends? What would you change in the admin's profile proposal?

Read the worked answer

License first. The contractors need Cases, so they need a Salesforce license. A Salesforce Platform license cannot open Cases at all, so confirm license counts before designing anything.

Profile vs permission set

Keep one minimal profile (Contractor Base) that grants only what cannot be granted elsewhere: login hours live only on profiles, so that is the one legitimate reason for a profile here.
Do not clone Standard User. Every clone inherits the baseline's accumulated permissions, which is exactly how the org acquired its Modify All Data problem in the first place.
Put functional rights in permission sets: Case Read - Contractor and Inspection Edit - Contractor, and set a permission set expiration date at project end. Expiration is the only native mechanism that lapses access on a date; deactivating the user is still manual, so schedule a weekly report of assignments to those two permission sets and a deactivation checklist.

What not to rely on

Login IP ranges: contractors are on unmanaged home networks; an allowlist breaks the first time an ISP reassigns an address.
Login hours: they are a speed bump, not a control, and are not enforced for connected-app/API sessions.
Session timeout: Session Settings are org-wide, not per profile, so contractor session length has to be handled at the identity provider.

Export control: remove Export Reports and Export Data from the base profile and control distribution through report folder access.

2. The 12 users with Modify All Data: what is the remediation plan, and what is the risk of removing it only from the Contractor profile?

Read the worked answer

Why the narrow fix fails: the grant is sitting in the shared baseline behind all eight department profiles, so editing Contractor only fixes the contractors. The 12 internal users keep bypassing sharing and keeping delete rights on every object with records they can see.

Remediation sequence

Establish the source of the permission per user (profile, permission set, or permission set group) rather than assuming it is the profile.
Build the blast-radius report: every user whose effective access changes if the permission is removed. Removing Modify All Data reduces visibility of records not shared with the user, so users who rely on it as a sharing shortcut will lose records mid-quarter.
Replace it with intent: a Support Lead - Modify All Cases permission set for the people who genuinely need it, plus sharing rules where broad visibility is the real requirement.
Check integrations and any automation running in those users' context before you strip it.
Do the removal in a full sandbox first, then deploy in a maintenance window across all eight profiles, and re-baseline the profiles so the next clone does not reintroduce it.

The underrated risk: Modify All Data also grants delete. An accidental mass delete is only recoverable for 15 days via Recycle Bin, and removing the permission after an incident is too late.