Documentation does not rot at random. It rots on a schedule, and the schedule belongs to Salesforce.

Three major releases land each year. Admins change configuration continuously between them. Agents now change configuration too. Against that, a Confluence page edited by hand whenever somebody remembers has no chance, and the usual response is to write more of them.

A better response starts from an awkward fact: most of what teams write by hand is already recorded somewhere machine-readable. Not all of it, and the part that is missing is the part worth paying a human to write. Separating those two is the entire discipline.

Your org logs every setup change and names the AI agent that made it

Start with what already exists, because teams routinely document around it.

Setup Audit Trail tracks setup changes made by admins. Salesforce’s Help page is specific about what it gives you. On screen, history shows the 20 most recent setup changes made to your org, listing the date of the change, who made it, and what the change was. To get more, you download the complete setup history for the past 180 days, and after 180 days, setup entity records are deleted.

Two columns in that log matter more than the dates. When a delegate such as an admin or support representative makes a change on behalf of an end user, the Delegate User column shows the delegate’s username while the User column shows the person who granted access. And in a line worth reading twice: if an admin makes a change using an AI agent via Setup with Agentforce, which Salesforce marks Beta, the agent’s name and ID are listed in the AI Agent column, with the admin listed in the User column.

Configuration changes now carry agent attribution at the platform level. Any documentation standard written before that column existed has no field for it.

Salesforce also points at an agentic way to query the log rather than scroll it, suggesting you ask the Setup agent something like showing changes made by a named user during the last 100 days. Reading the audit trail is no longer a manual task, which removes the most common excuse for not reading it.

Setup Audit Trail proves a change happened and discards why

Here is where the log stops, and where documentation has to start.

An entry telling you that a validation rule was modified does not tell you what inside the rule changed, which requirement drove it, or which alternative was rejected. The log is an attendance register, not an explanation. Add the 180-day deletion and a change made nineteen months ago has no surviving record at all beyond its effect on the org.

So the durable content of Salesforce documentation is reasoning, constraints and intent. Configuration state is a renewable resource, retrievable from the org whenever you want it. Decision rationale is not renewable, and once the people who hold it leave, it is gone. Design decisions and their rejected options belong in the document that records them before build, and what the org currently contains belongs in a read of the metadata itself.

Teams get this backwards with impressive consistency. They hand-maintain field inventories that a metadata query regenerates in seconds, and they leave the Description field on those same fields empty.

Salesforce sorts every release feature into four activation classes

Release notes are the second half of this problem, and most teams summarize them wrongly because they summarize the wrong axis.

Salesforce publishes a matrix called How and When Do Features Become Available, and its columns are the useful part. Every feature in a release is marked against four of them: Enabled for users, Enabled for administrators and developers, Requires administrator setup, and Contact Salesforce to enable.

Only the first class changes anything on its own. Salesforce’s own framing of that column is a communications instruction: some features affect all users immediately after the release goes live, so consider communicating these changes to your users beforehand, while other features require direct action by an administrator before users benefit.

A release summary listing twenty interesting features is noise. A release summary listing the three that are enabled for users in your edition, and the two requiring setup that someone has now been assigned, is documentation.

Release Updates carry a Complete Steps By date that can move

One category inside the notes behaves differently from the rest and deserves its own treatment.

Salesforce describes release updates as improvements to the performance, logic, security and usability of its products, notes that some affect existing customizations, and states the mechanism plainly: every time a release update is created, it gets scheduled to be enforced in a future release. Schedules are announced as soon as they are known, and here is the part documentation has to respect, occasionally updates are postponed or canceled.

So the date to record is not the release that introduced the update. Salesforce calls it the Complete Steps By date, and many updates offer a Test Run option letting you enable the update and examine the changes to your org, customizations included, before that date arrives.

Documentation treating a release as the unit of change misses all of this. An update can appear in one release, sit unenforced through the next, and become mandatory in a third, so three sets of release notes mention it and only the date on the Release Updates page in Setup decides anything. Because that date can shift, a document stating it needs a last-checked stamp beside it rather than a copied value. The approval rhythm that should own those dates sits in the venue where a dated change gets accepted.

Release scope spans close to thirty sections, so filtering beats reading

Nobody reads a Salesforce release note end to end, and pretending otherwise is why release documentation gets skipped.

The Winter ’27 availability matrix is organized into section after section: Salesforce Overall, Release Updates, Agentforce and Generative AI, AIforce, Analytics, Automation, Commerce, Customization, Data 360, Deployment, Development, Experience Cloud, Field Service, Hyperforce, Industries, Marketing, MuleSoft, Mobile, Partner Cloud, Platform, Public Sector, Revenue Management, Sales, Salesforce CMS, Salesforce Suites, Security Identity and Privacy, Service, Slack Integrations, and more.

Close to thirty sections, of which a given org runs perhaps four. This is the single best use of a language model in Salesforce documentation, and it is not drafting prose. It is filtering a large structured document against a known inventory of what your org actually uses, then producing a short list with activation classes attached. The source is public, the output is checkable against it, and a wrong answer is visible immediately.

Preview and non-preview instances put your documentation on two clocks

A detail that quietly breaks release documentation: not every environment gets the release at the same time.

Preview instances are upgraded roughly six weeks ahead of production during every major release, and non-preview sandboxes see new features only when they are generally available, which puts a gap of roughly six weeks between the two. Which environments sit on which clock is covered in how you plan environments and their upgrade timing.

Documentation written against a preview sandbox describes behavior that production does not have yet, and documentation written against production misses what testers are already seeing. Stating which instance and which release a document describes costs one line and prevents a recurring class of confusion.

Three documentation classes, and only one of them should be written by hand

This is the operating model the rest of the page has been building toward.

Generated. Anything derivable from metadata: object and field inventories, automation lists, permission set contents, integration endpoints, dependency maps. Never maintain these by hand. Regenerate them, and treat any hand-written copy as a liability, because a stale inventory is worse than no inventory. Someone trusts it.

Subscribed. Anything Salesforce publishes on a cadence: release features filtered to your stack, Release Update Complete Steps By dates, retirements. You do not write these, you subscribe to them and filter them.

Hand-written. Decision rationale, rejected alternatives, business context, constraints you accepted, and the reasoning behind every deliberate departure from a standard pattern. This is the irreplaceable class, it is small, and it is what the other two exist to protect.

Most documentation effort is spent in the first class, where it has the least value and the shortest shelf life. Moving that effort to the third is the whole return.

One practical move is worth more than a documentation portal: use the platform’s own description fields. Descriptions on fields, objects, flows and permission sets travel with the metadata, survive deployment, appear to the next person in the place they are already looking, and can be retrieved programmatically. Documentation stored inside the thing it describes cannot drift away from it.

Agent documentation has no settled convention, which is a reason to write it now

Agentic scope introduces a documentation gap the ecosystem has not closed.

With deterministic automation you can read a flow and know what it does. With an agent you can read its instructions and still not know how it behaves, because behavior emerges from instructions, available actions, grounded data and a reasoning engine interacting. Salesforce’s own lifecycle guidance for agents treats testing and monitoring as continuing phases rather than one-time gates for exactly this reason.

Three things are worth recording for every deployed agent, and none has a standard home yet. What the agent is allowed to do, expressed as scope boundaries rather than a list of actions. What it should escalate, and to whom. What it was observed doing, taken from production traces rather than from the design intent. That third item is new in kind. Deterministic systems do not need a record of observed behavior because behavior equals specification; agents need it because behavior is evidence. How that evidence gets produced before release is covered in the evaluation cycle that proves agent behavior.

Write these while the build is fresh. There is no convention to copy, which means there is also nothing stopping you from setting one.

Current documentation reduces support cost by removing the question, not the ticket

Worth being precise about the mechanism, because the usual claim is vague.

Documentation does not reduce support cost by helping people resolve tickets faster. It reduces cost by preventing the investigation that precedes the ticket. An admin who can see why a validation rule exists does not open an inquiry about it. A developer who can see which integration owns a field does not spend an afternoon finding out. A new joiner who can read the rejected alternatives does not propose one of them in week three.

Each of those is an hour that never gets logged anywhere, which is why documentation value resists measurement and gets cut first. What you can measure is narrower and still useful: how often a change request arrives with the wrong assumption attached, and how long the discovery phase of a BAU request takes. Both move when the written record is current. Dead configuration that documentation keeps describing is a separate cost, addressed in retiring the configuration nobody uses.

GetGenerative.ai keeps the written record attached to the work that produced it

Documentation fails for a boring reason. Writing it is a separate task from doing the work, it happens after the decision is cold, and it competes with the next deadline.

GetGenerative.ai removes the separation. Its Discovery Agent captures scope, schedule and resourcing as discovery happens; its Design Agent produces the solution design from that same material; its Metadata and Build Agents work against the design; and its Testing and Support Agents carry it into run. Because one project context runs through all six, the written record is a byproduct of delivery rather than a chore scheduled after it. The alternatives an architect ruled out in week two are still attached to the design in week nine.

For an org already live, the same logic applies to business-as-usual change, where the Support Agent holds the thread between what was asked, what changed and what the documentation now says. You can see what ongoing org support covers if that is the half of the problem you have.

Where AI helps, and the one place it should not be trusted

A clear division, based on whether output can be checked against a source.

Use it for filtering release notes against your inventory, generating first-pass descriptions from metadata for human approval, summarizing audit trail exports into change narratives, translating technical designs for business readers, and detecting drift by comparing a document against current metadata. Each has a verifiable source, so an error is catchable.

Do not use it to reconstruct rationale after the fact. A model asked why a design decision was made will produce a fluent, plausible, invented reason, and because it reads exactly like the real thing nobody will question it later. That is the one documentation failure worse than a blank page, since a blank page tells the truth about what is known.

Record reasoning at the moment of decision or accept that it is gone. No tool recovers it afterwards.

Common questions on keeping Salesforce documentation current

How do you keep Salesforce documentation up to date?

Split it by source. Regenerate anything derivable from metadata rather than maintaining it, subscribe to anything Salesforce publishes on a cadence such as release features and Release Update Complete Steps By dates, and hand-write only decision rationale and constraints. Store descriptions in the platform’s own description fields where they travel with the metadata and survive deployment.

What does Setup Audit Trail actually record?

Setup changes with the date, who made the change, and what the change was. The screen shows the 20 most recent entries and a download gives the complete setup history for the past 180 days, after which setup entity records are deleted. A Delegate User column names anyone acting on another user’s behalf, and an AI Agent column names the agent and its ID when a change is made through Setup with Agentforce, which is in Beta.

How long does Salesforce keep setup change history?

180 days. After that, setup entity records are deleted, so anything you need beyond six months has to be exported and stored outside the org before the window closes.

What should a Salesforce release note summary include?

Each relevant feature with its activation class from Salesforce’s availability matrix, which marks features as enabled for users, enabled for administrators and developers, requiring administrator setup, or needing you to contact Salesforce. Features enabled for users need advance communication because they change behavior on their own. Release Updates need their Complete Steps By date recorded, and rechecked, since Salesforce can postpone or cancel a scheduled update.

Can AI write Salesforce documentation?

For anything with a checkable source, yes: filtering release notes against your org inventory, drafting descriptions from metadata, summarizing audit exports, and flagging where a document and the current metadata disagree. It should not be asked to reconstruct why a past decision was made, because it will produce a plausible invented rationale that reads like a record and is not one.

What needs documenting for an Agentforce agent?

Scope boundaries describing what the agent may and may not do, escalation conditions naming what gets handed to a human, and observed behavior drawn from production traces. The third has no equivalent in deterministic automation, where behavior matches specification, and it matters for agents because behavior is evidence rather than a given.

Presales gets judged on whether the deal closed. That is the wrong test, and it is why the function keeps getting measured a quarter too late.

A better test is whether the work done before signature holds up during delivery. A deal that closes on a scope nobody can build at the price quoted is a presales failure that arrives dressed as a win, and the person who finds out is the delivery lead three weeks in.

What follows treats presales as a sequence of decisions with evidence attached, because that is the only version of it that predicts margin.

PMI measured what separates high performers, and it happens before execution

Start with evidence, since this topic usually runs on assertion.

The Project Management Institute published the 16th edition of its Pulse of the Profession on 12 May 2026, titled Driving Success in Complex Projects. Its headline numbers describe an environment most Salesforce practitioners will recognize: 97 percent of project professionals managed at least one complex project in the past year, more than half of all projects now qualify as complex, and 81 percent say projects have become more complex in recent years, with 37 percent describing a significant increase.

Three findings in that report bear directly on presales.

One is the gap itself. Nearly one third, 31 percent, of complex projects fail to achieve the full scope of their intended benefits, which PMI notes is more than twice the rate reported for projects overall. Complexity does more than slow delivery. It erodes what the project was bought for.

Another is where high performers act differently. Among the practices PMI associates with effective complexity management, the first listed is sponsor alignment at initiation, which it defines as establishing shared understanding of what success looks like before execution begins. That practice is used by 39 percent of high performers against 30 percent of low performers. Both numbers are low, and the first one is the ceiling.

Third is the payoff. Projects that navigate complexity effectively are five times more likely to succeed, with PMI putting the success rate at 88 percent against 14 percent for teams only slightly effective or ineffective at managing it.

Read those together and presales stops looking like a sales support function. Shared understanding of success, established before execution, is a presales deliverable. Nobody else is in the room early enough to produce it.

Qualification decides whether the rest of the process is worth running

Every stage below produces something. This one produces a decision about whether to continue, and it gets skipped more than any other under pipeline pressure.

Four things need establishing on or shortly after the first call, and none requires a solution.

A named problem with a cost attached. Not an interest in Salesforce. A consequence somebody is already paying for, expressed in money, hours or risk. Without it there is no business case to build later, because there is nothing to compare the investment against.

An owner who can say yes. Named, with their approval threshold known. A sponsor who has to escalate your number is a sponsor whose timeline you cannot forecast.

A reason this is happening now. A compliance date, a contract expiry, a system being switched off, a funding window. Deals without a forcing event do not close, they age.

A budget range somebody has acknowledged. Not a precise figure. A range that neither party flinches at, established before you spend a week scoping.

PMI’s framework finding applies here with unusual force: projects using frameworks succeed at a rate of 72 percent against 61 percent without them, yet 35 percent of professionals used no framework at all on their most recent complex project. A written qualification standard is the cheapest framework a presales team can adopt, and most do not have one.

Discovery earns its name by changing what you would have proposed

Discovery that confirms your initial assumption was not discovery, it was a demo with questions.

Three layers need covering, and skipping the third is the usual cause of post-signature argument.

Process first. How the work runs today, including the parts that live in spreadsheets and the exception paths people have stopped mentioning because they are normal. Then data. What exists, where, in what state, and who owns it, because data condition determines more of your effort than feature count does. Then constraints. Integration dependencies, compliance obligations, release windows, the internal politics of a team that does not want this, and whatever the previous failed attempt taught the organization.

Constraints are where deals get mispriced. A requirement list is roughly the same length whoever writes it. What varies by an order of magnitude is the environment the requirements have to be met in.

Discovery output then routes forward: requirements get classified into what the platform does, what gets configured, what gets built and what gets dropped, which is handled in how each requirement is dispositioned before design, and the numbers attach through the method that makes an estimate defensible.

Einstein Conversation Insights turns recorded calls into searchable entities

Here is the stage where language processing does real work rather than decorative work, and Salesforce ships the mechanism.

Discovery produces conversation, and conversation is where requirements first get stated, usually imprecisely and rarely written down the same day. Einstein Conversation Insights records and analyzes calls for mentions of specific keywords, phrases and points of interest, in Salesforce’s own description, giving managers and reps visibility into mentions of competitors, products, custom keywords, pricing discussions and next steps.

Its limits are worth knowing, because they force a choice. An org can hold up to 100 custom insights, each insight can carry a maximum of 25 keywords, and each keyword is limited to 255 characters. Twenty-five keywords per insight is not many, which means you are selecting the entities that matter rather than cataloging everything: the integration names that signal scope, the compliance terms that signal effort, the competitor names that signal deal shape, the words that appear when a prospect is describing a workaround rather than a requirement.

What changes a presales team’s behavior is the aggregate view rather than the single call. Salesforce describes sales leaders extracting conversation trends and visualizing insights across voice and video calls, which turns a quarter of discovery conversations into evidence about which objections recur and which scope signals keep appearing.

Two considerations belong in your plan before anyone switches this on. Salesforce states that Einstein Conversation Insights stores some data using a public cloud provider located in the United States, and that data from European orgs is stored in Europe while processing occurs in the United States, which is a conversation to have with a prospect’s legal team rather than after it. And it is not available everywhere: Salesforce lists it for Starter, Pro, Enterprise, Performance, Unlimited and Agentforce 1 Sales editions, and states it is not supported in Experience Cloud sites or Government Cloud.

GetGenerative.ai runs discovery as a producing stage rather than a meeting

Presales work is mostly reformatting. One set of facts gets written into a discovery summary, a requirement list, an estimate, a proposal and then a statement of work, each time by hand, each time with a chance to drift from the version before it.

GetGenerative.ai collapses that. Its Discovery Agent takes discovery inputs and produces scope, schedule and resourcing together, so the estimate and the scope derive from one record rather than being reconciled later. Its Design Agent carries the same material into solution design, and because the Build, Testing and Support Agents work from that design, the reasoning captured during presales is still attached when delivery starts. That makes the handoff problem above structural rather than cultural, and one shared project context is what removes it.

Judgment stays human. Qualification, the read on a sponsor, and the decision to walk away are not agent work. Drafting, structuring and keeping five documents consistent are. You can see what the agents cost to run before putting a pipeline through them.

Solution shape precedes solution detail, and the shape is what you price

After discovery, resist designing. What the deal needs at this point is shape, not specification.

Shape means the decisions that move the number by multiples: single org or multiple, which clouds are in the first phase and which wait, what integrates in release one, whether data migration carries full history or a cutoff, and how much of the requirement list is being met by configuration against build. Detail means field names, and field names have never changed a price.

Which pricing model fits what you have learned is its own decision, covered in choosing between fixed, time and materials and outcome-based. Demos belong here too, after shape and before commercials, because a demo given before you know the shape is a product tour, and a demo structured to win the room depends on knowing which three decisions the room is actually weighing.

Proof exists to test the assumption that would hurt most

Not every deal needs a proof stage. Those that do carry most of their risk in a single assumption.

Name it explicitly and the proof designs itself. If the risk is that legacy data is too poor to migrate, the proof is a sample load with a reconciliation result. If the risk is that an integration endpoint cannot deliver the volume, the proof is a timed call against the real endpoint. If the risk is user adoption, the proof involves actual users, not stakeholders.

Scope the proof to that assumption and nothing else. Proofs expand to fill the time available, and a proof that demonstrates eleven capabilities while leaving the risky assumption untested has cost you weeks and bought you nothing. Whether the right instrument is a short technical proof or a production pilot with real users is a separate choice, set out in which one proves value faster.

Commercials convert what you learned into the right contractual shape

Pricing is a conversation the previous stages have already decided, if they were run properly.

Scope certainty, not deal size, selects the model. Where discovery produced a bounded scope with known data condition, fixed price is defensible and the client gets the certainty they want. Where it did not, a fixed price is a bet whose odds you have not calculated, and your own estimate uncertainty is the thing being wagered. Time and materials with a good-faith estimate is the honest instrument there, and saying so out loud is a stronger position than most presales teams expect.

A business case runs alongside this rather than after it, since a sponsor needs a number they can defend internally before they can approve one externally. That artifact is built in the business case a CFO will approve.

Everything above exists to make one document signable

The SOW is where presales output becomes enforceable, and its quality is a direct readout of the process that produced it.

A vague scope section means discovery did not finish. Missing client obligations means nobody established who would provide access, data or decisions. No change control means the forcing event was never understood, so nobody considered what happens when priorities move. Acceptance criteria absent means success was never defined, which is precisely the sponsor alignment PMI found separates high performers from everyone else.

Which clauses carry the commercial risk, and how the supplier side gets drafted, is the subject of the clauses a Salesforce SOW has to carry. What matters here is the direction of causation: you cannot write a tight SOW to compensate for loose presales. That document exposes the process behind it.

Handoff is a stage, and skipping it is where margin leaks

Presales usually ends at signature. Margin does not.

Three things have to travel into delivery, and only the first normally does. Scope always transfers, because it is in the contract. Reasoning, meaning why the phase boundary fell where it did and which alternatives were rejected, usually transfers as a conversation and then evaporates. And the assumptions, every one of which is a commercial risk that somebody in delivery now owns without having agreed to it.

Run the handoff as a stage with an output. A delivery lead who can state the three riskiest assumptions in the deal has been handed over to. One reading the SOW for the first time in week one has not. Where that reasoning gets recorded so it survives the transfer is covered in the document that holds design decisions and rejected options.

Questions that come up when the process gets written down

What are the stages of a Salesforce presales process?

Qualification, discovery, solution shape, proof where the risk warrants it, commercials, SOW, and handoff into delivery. Each stage produces something specific and each has conditions that should stop the deal rather than advance it. Qualification establishes a named problem with a cost, an owner who can approve, a forcing event and an acknowledged budget range.

What is the difference between presales and sales engineering?

They describe the same function, with sales engineer and solution engineer being the more common job titles. Search demand reflects this: Google Trends for the twelve months to October 2026 shows sales engineer attracting substantially more interest than presales process, which registers almost no measurable volume. Both titles describe identical work: qualifying, discovering, shaping a solution and defending the commercials behind it.

How long should Salesforce presales take?

Long enough that discovery changed what you would have proposed, and no longer. A useful constraint is the forcing event established during qualification, since that date sets the schedule. A deal with no forcing event has no natural length, which is one reason those deals age rather than close.

Does presales quality really affect delivery margin?

PMI’s 2026 Pulse of the Profession found that 31 percent of complex projects fail to achieve the full scope of their intended benefits, more than twice the rate for projects overall, and that establishing shared understanding of success before execution begins is a practice used by 39 percent of high performers against 30 percent of low performers. That shared understanding is produced during presales or not at all.

How can AI help in Salesforce presales?

Two uses hold up. Einstein Conversation Insights records and analyzes calls for mentions of specific keywords, phrases and points of interest, capped at 100 custom insights of 25 keywords each, and lets leaders extract conversation trends across voice and video calls. And generative drafting keeps the discovery summary, requirement list, estimate, proposal and SOW consistent, since those documents restate the same facts. Qualification judgment and the decision to disqualify stay with people.

What should transfer from presales into delivery?

Scope transfers automatically, because it is contractual. Reasoning behind the solution shape, including which alternatives were rejected and why. And the assumptions, each of which is a commercial risk that delivery inherits. A handoff is complete when the delivery lead can state the three riskiest assumptions without reading the contract.

One disambiguation before anything else, because two different things carry this name.

If you arrived looking for the AppExchange Security Review, the assessment an ISV passes before listing a managed package, this is not that page. This covers reviewing permissions inside your own org: who can see which records, which fields, and through what mechanism. Both get called a Salesforce security review, and the second one is the review nobody schedules until something goes wrong.

It also became more interesting in June 2026, because Salesforce changed its position on the thing most permission roadmaps were built around.

Salesforce cancelled the retirement of permissions in profiles

Anyone planning permission work from guidance written before mid-2026 is working to a deadline Salesforce has since withdrawn.

Salesforce’s help article Permissions in Profiles Retirement Cancelled, published 6 June 2026, is direct about it. Profile permissions had been scheduled for retirement from Spring ’26. Salesforce now states that the enforcement is cancelled, and gives two reasons for the reversal: what customers told it, and feature gaps that remain unclosed.

Note the word. Cancelled, not postponed. This followed an earlier retreat from enforcing the Spring ’26 end-of-life date, so the pattern is two steps back from a stated deadline.

That same article keeps the recommendation while removing the compulsion. Profiles will continue to support permissions for now, and Salesforce recommends transitioning to a permission set-led security model for improved flexibility and scalability. It also names where the investment is going: improved user management in Setup, permission sets and permission set groups, and summary views with admin usability improvements.

What changes for you is the argument, not the direction. Migration was a compliance project with a date attached. Now it is an architecture decision you justify on merit, which is harder to fund and easier to postpone indefinitely.

GetGenerative.ai enumerates the permission model before anyone argues about it

Permission reviews stall at the first step, which is finding out what you currently have.

Nobody can review what they cannot enumerate, and a mature org holds permissions across profiles, permission sets, permission set groups, muting sets, sharing rules, role hierarchy, territory assignments, manual shares and whatever Apex sharing somebody wrote in 2019. Assembling that picture by clicking through Setup is why these reviews get scheduled and then quietly dropped.

GetGenerative.ai’s Metadata Agent reads the org’s permission metadata directly, which turns the inventory step from weeks of manual collation into something you can put in front of stakeholders on day one. The Design Agent then holds the target model, so the gap between current and intended state is a document rather than an argument. Where that fits a wider review of org condition is covered in the assessment that reads an org through its metadata.

Judgment stays with people. Deciding that finance should not see deal margins is a business decision, and no agent should make it. Finding every place that permission is currently granted is clerical work that should never have consumed a consultant’s week. If the ongoing version of that is your problem, what BAU org support covers sets out the running model.

Salesforce now assigns profiles six responsibilities and permission sets ten

Cancellation came alongside the clearest division of labor Salesforce has published, which makes it the right basis for a review standard.

Two instructions accompany that table and both are quotable in a review document. Assign users the Minimum Access – Salesforce profile, or a clone of it, as the stated best practice. And avoid adding permissions directly to profiles where possible.

Read the right-hand column as your review scope. Every item there is something that should be grantable and revocable without touching a profile, and in most orgs several of them are not.

Permission set groups align to job function, not to person

Groups are the mechanism that makes a permission set model manageable rather than merely correct.

Salesforce’s guidance is to combine multiple permission sets into permission set groups, align those groups with user roles or job functions, and use them to simplify assignment and management. Design discipline here is simple: a group represents a job, a permission set represents a capability. One capability can appear in several jobs, which is the whole point and the reason this scales where profile cloning does not.

A review catches the failure mode quickly. Count your permission sets and your users. If the ratio is close to one to one, you have rebuilt profiles with a different object name and inherited none of the benefit.

User Access Policies automate assignment, which is where migrations actually fail

Designing the target model is the part teams enjoy. Moving thousands of users onto it is the part that stalls.

Salesforce’s migration recommendation runs in five steps: plan and document your current permissions model, design permission sets and groups based on user roles, use User Access Policies to automate assignments, test thoroughly in a sandbox environment, then roll out to production.

Step three is the one that makes the rest survivable. Manual reassignment across a large user base is slow, error-prone and impossible to repeat, so the policy mechanism is what converts a one-off project into a rule that keeps applying to new joiners. Step four deserves its own emphasis too, because permission changes behave differently against real data volumes and real role hierarchies, and the environment where that gets proven is a planning decision rather than an afterthought.

Field-level security is the fastest-rising question in this area

Worth knowing what people are actually asking, because it tells you where a review gets challenged.

Google Trends over the twelve months to late October 2026 puts average interest in permission sets slightly ahead of salesforce security review, with salesforce sharing rules far behind both. More useful than the ranking is the movement: the fastest-rising related query attached to salesforce security review is field level security in salesforce, up around 120 percent.

That matches where reviews find problems. Object-level access is visible and gets audited. Field-level security hides inside page layouts and permission sets, and a field that should be invisible to a role is usually invisible on the layout rather than restricted by permission, which means it remains available through reports, the API and now through agents.

Agents lose user identity by default, which breaks least privilege silently

Here is the part of a permissions review that did not exist two years ago, and it is the one with the sharpest consequences.

Salesforce’s architecture guidance on end-user identity propagation in agents states the problem plainly. User identity is lost by default. When an agent calls an MCP server or downstream API using client credentials, the request carries the agent’s service identity rather than the end user’s, and the downstream service has no way to know which user initiated the action, which makes per-user authorization and audit trails impossible.

Salesforce also names the trap on the other side. Passing the original user token through every hop violates the principle of least privilege, while using a service account loses the user’s identity. Neither default is acceptable, and the guidance is equally clear that propagating user tokens where they are not needed expands the attack surface.

Three patterns resolve it, and a review should establish which one applies to each agent action.

On-Behalf-Of, where user identity is preserved through a token exchange scoped to each downstream service, with no user interaction. Correct for user-specific data inside one trust domain, such as an agent retrieving a customer’s own records.

Server-to-Server, where user identity is deliberately not propagated and the calling service’s own credentials are used. Correct for public or system-level data, where propagating a user token would add exposure for no gain.

In-Task Authorization Code, where the user authenticates inline with an external provider during the conversation. Correct for cross-domain and higher-risk operations, where a token from your identity provider means nothing to the target system.

One architectural principle underneath is worth carrying into your standards: identity propagation is enforced at the gateway layer rather than inside agents or services, so agents hold no authentication logic. Salesforce’s own summary of the stakes is the line to quote in a governance paper. Without trusted identity propagation, governance is incomplete, because you can catalog and orchestrate agents and still not ensure they act within the boundaries of the user’s authorization.

An agent inherits a permission model it did not design

Follow that through to the practical review question, because it reframes old findings as new risks.

An agent answers in natural language from whatever its user context can retrieve. Over-granted field access that survived five years because nobody built a report on it becomes a sentence in a chat window. A sharing rule written broadly for convenience becomes an answer about an account the asker was never meant to see. Your permission model did not change. The number of ways to interrogate it did, which is the whole shift.

Two review items follow. Every agent needs a named user context with its permissions documented, rather than inheriting an administrator’s. And the checks you run before switching an agent on should include a read of what that context can reach, which is part of the readiness checks that precede turning agents on.

Sharing grants record access, and only one mechanism takes it back

Permissions answer what a user can do with an object. Sharing answers which records, and the two get conflated in most review conversations.

Sharing starts restrictive and opens up. Organization-wide defaults set the floor, then role hierarchy, sharing rules, teams, manual shares and Apex sharing grant access above it. Everything in that stack grants, which is why an org whose defaults were set to Public Read Write in year one cannot be tightened later without discovering which business processes quietly depended on the gap.

One mechanism does subtract, and a review should know its limits before relying on it. Restriction rules filter the records a user already has access to, so they reach only the ones matching criteria you specify, applying on top of organization-wide defaults and sharing rules. Four constraints matter. They cover a limited object set, named by Salesforce as custom objects, external objects, contracts, events, tasks, time sheets and time sheet entries, so Account, Opportunity, Contact and Case are not among them. They support only the EQUALS operator, with no AND or OR. Enterprise and Developer editions allow up to two active rules per object, Performance and Unlimited up to five. And they are bypassed entirely by View All Records or View All Data for reading, and by Modify All Records or Modify All Data for reading, editing and deleting.

Scoping rules are the mechanism most often mistaken for this one. Salesforce is explicit that a scoping rule does not restrict access to other records a user sometimes needs. It filters what appears by default in list views, reports and SOQL, and the user can still reach anything their sharing allows. Treating a scoping rule as a control is a review finding, not a mitigation.

A review should state the organization-wide default per object and the justification for every mechanism layered on top. Mechanisms without a stated reason are the ones to question, because each one is a standing grant that outlives whoever requested it. Who approves changes to any of this belongs in the forum where access decisions get signed off, and the data-side policies that sit beside it are covered in the rules governing what agents may ground on.

What a review should produce, in order

Findings, not observations. Each item needs a current state, an intended state and an owner.

Start with an enumeration: every profile with permissions attached, every permission set and group, the organization-wide default per object, and every sharing mechanism in force. Then compare against Salesforce’s own split, treating anything in the permission-set column that currently lives on a profile as a finding. Record each one the way a design decision and its rejected alternative get written down, since a permission granted without a recorded reason is the thing you will be unable to revoke later.

Next, test field-level security against the API rather than the page layout, since that is where the gap hides, and check whether any control you are relying on is a scoping rule rather than a restriction rule. Then document each agent’s user context and what it can retrieve, and assign each agent action one of the three identity patterns.

Schedule the re-run before you close the first one, because permissions drift with every release and every joiner, and the cutover checks that precede go-live are the wrong place to discover a sharing default nobody reviewed.

Finish with the two questions that decide whether the review was worth running. Can a permission now be granted and revoked without editing a profile? And can you name, for any sensitive field, every path by which a user could reach it, reports and agents included?

Questions that come up during a permissions review

Did Salesforce retire permissions in profiles?

No. Salesforce announced the retirement starting in Spring ’26 and then cancelled the enforcement, confirmed in a help article published 6 June 2026, citing customer feedback and remaining feature gaps. Profiles continue to support permissions, while Salesforce still recommends moving to a permission set-led model for flexibility and scalability.

What belongs in a profile versus a permission set?

Salesforce assigns profiles the default settings: default assigned apps, default record types and page layouts, login hours, login IP ranges, password policies and session settings. Permission sets and groups take object permissions, field-level security, user permissions, custom permissions, tab settings, non-default record types, Visualforce page access, Apex class access, connected app access and non-default assigned apps. The stated best practice is to assign the Minimum Access – Salesforce profile or a clone, and to avoid adding permissions directly to profiles.

How do you migrate from profiles to permission sets?

Salesforce’s recommended sequence is to plan and document the current permissions model, design permission sets and groups around user roles, use User Access Policies to automate the assignments, test thoroughly in a sandbox, then roll out to production. The automation step is what makes the migration repeatable for new joiners rather than a one-time exercise.

Is the Salesforce Security Review the same as reviewing permissions?

No, and the name collides. The AppExchange Security Review is the assessment an ISV passes before listing a managed package, run by Salesforce’s product security team. Reviewing profiles, permission sets and sharing is internal org work on who can reach which records and fields. Search results for the phrase return mostly the AppExchange process.

What does least privilege mean for Agentforce agents?

That each agent acts within the authorization of the user it is serving rather than with broad service credentials. Salesforce’s architecture guidance notes that user identity is lost by default when an agent calls a downstream service with client credentials, which makes per-user authorization and audit trails impossible, while forwarding the original user token everywhere violates least privilege. Three patterns cover the cases: On-Behalf-Of preserves identity within a trust domain, Server-to-Server deliberately omits it for public data, and In-Task Authorization Code asks the user to authenticate inline with an external provider.

Why does field-level security matter more now?

Because agents add retrieval paths. A field hidden on a page layout but not restricted by permission remains reachable through reports, the API and agent responses, so a layout-based control that passed audits for years can surface the value in a sentence. Field level security in salesforce is also the fastest-rising related search attached to this topic, up around 120 percent over the year to October 2026.

Most migration plans are a mapping spreadsheet with a date on it. Source field, target field, transformation rule, owner. Useful, and not the part that fails.

Migrations fail on sequence. Some operations in Salesforce can be repeated until they are right, and a few can be done exactly once, with the only remedy being to delete what you loaded and load it again. A plan that does not distinguish between those two categories is a schedule, not a plan.

What follows is organized by that distinction rather than by phase, because phases are where this topic usually gets written and phases are not what hurts you.

Audit fields accept values once, and a mistake means export, delete and reload

Start here, because this is the hardest door in a Salesforce migration to walk back through.

Salesforce lets you write normally read-only system fields during a migration, so that records appear to have been created at the time they were originally created on your old system. Four fields are in scope: CreatedByID, CreatedDate, LastModifiedByID and LastModifiedDate.

Two scoping details get missed, and both change a plan. The feature applies to an enumerated list of objects, which Salesforce gives as Account, CampaignMember, CareService, Case, CaseComment, CodeSet, Contact, ContentNote, ContentVersion, Contracts, EmailMessage, FeedComment, FeedItem, FinancialGoal, FinancialPlan, HealthCondition, Idea, IdeaComment, Lead, Opportunity, Quote, Vote, Work Order, Task, Event, Attachment, and all custom objects. Check your object list against that one before promising historical dates on anything, because several standard objects that turn up in migrations, Opportunity line items and Orders among them, are absent from it.

The second detail is a gift rather than a constraint. On Lead, five conversion fields can also be set on insert: IsConverted, ConvertedDate, ConvertedAccountId, ConvertedContactId and ConvertedOpportunityId. Lead conversion history is normally the first casualty of a migration, and this is how it survives, provided the Accounts, Contacts and Opportunities those fields point at already exist when the Leads load, since a lookup cannot reference a record that is not there yet. Converted Leads therefore land later in the load sequence than their place in the business story suggests, which is worth stating in the plan rather than discovering mid-load.

The constraint is in Salesforce’s own words on the Create Audit Fields article. Since these fields are intended to be audit fields, they can only be set on create, not on update, and if the records already exist in Salesforce, they must be exported to a CSV file, deleted in Salesforce, and then imported with the updated information as new records.

Read what that implies for your plan. There is no corrective update. A load that goes in with today’s date on five years of history is not fixed by a second pass, it is fixed by deleting the records and starting over, which means re-pointing every child record and every relationship you had already loaded on top of them.

Three practical consequences belong in the plan document:

• Salesforce states these fields can be set on INSERT and not on UPDATE or UPSERT, so an upsert-based load and historical audit dates cannot coexist on the same pass.
• Setting audit fields requires the Modify All Data permission, and a System Administrator has to enable the feature.
• Salesforce recommends enabling it only during data migration, which makes switching it off a named step in your cutover runbook rather than an afterthought.

Activity history loses its original dates in two documented cases

Here is the detail that separates a plan written by someone who has done this from one assembled out of best-practice articles.

Even with Create Audit Fields enabled, Salesforce documents two situations where the dates you supply do not survive. When a Task is inserted with an association to a Contact or Lead through WhoID, or to records such as Account, Opportunity or Campaign through WhatID, the LastModifiedDate and LastModifiedBy fields will not reflect the inserted value. And when Enhanced Email is enabled and EmailMessages are inserted, the Task records auto-created alongside them do not take the CreatedDate of the EmailMessage, they get the date of insertion.

Activity history is usually the largest object set in a CRM migration and the one business users check first. Discovering this after cutover produces the worst version of the conversation, because the data is correct, the configuration is correct, and the dates are still wrong.

Decide in advance which of these you accept. Options are to carry the original timestamp into a custom field that you control, to exclude auto-created Task records from reconciliation on date fidelity, or to tell users plainly which objects carry true historical dates and which do not. Any of the three is defensible. Silence is not.

Bulk loading manufactures ownership skew, which is a role hierarchy decision

Migrations load records as a service account or a single admin, and that is where this problem originates.

Salesforce’s platform sharing guidance defines ownership skew as a single user, role or group owning many records for an object, notes it can cause long running transactions and performance degradation when change occurs, and puts the recommended ratio of owner to records at 1:10,000.

The remedy is specific and it is a configuration decision, not a data decision. Where a single user owns more than 10,000 records, Salesforce’s stated best practice is that the owner’s user record should not hold a role in the role hierarchy, and if it must hold a role, that role goes at the top of the hierarchy in its own branch.

Two things follow for the plan. Your load user needs deciding before the first row goes in, with its role position set deliberately. And if records are meant to end up owned by real users, reassignment is a separate planned operation with its own duration, not a tidy-up task someone runs on the Monday after go-live.

Sharing recalculation decides your cutover window, and Support controls the switch

Volume turns a correct load into a long one, and sharing is usually the reason.

Salesforce is direct about the thresholds. Above two million accounts, with Teams or Enterprise Territory Management implemented, performance needs particular attention, because these are complex sharing model components that can produce a very large volume of share records and therefore long running transactions.

For bulk changes at that scale there is a feature called Defer Sharing Calculations, which lets you make the change and then have sharing calculations happen all at once, an approach Salesforce describes as typically more efficient and better performing for bulk changes. The part that belongs in your project plan rather than your technical design: it is a feature that Salesforce Customer Support enables. You cannot turn it on yourself at 2am on cutover weekend, so if your volumes warrant it, the request is a lead-time dependency with an owner and a date.

Load order follows the object graph, and external IDs make a rerun safe

With the one-way doors identified, ordering is mechanical.

Parents load before children, because a child row needs its parent’s identifier. Users and record types exist before anything that references them. Accounts precede Contacts and Opportunities, Opportunities precede their line items, and anything with a lookup waits for its target. Self-referencing hierarchies load in two passes, the records first and the parent references second.

The piece teams skip is making every pass repeatable, and it needs stating carefully because of the audit field rule above. Put an external ID field on every migrated object holding the source system’s primary key, populated on the way in.

On passes where you are not setting audit dates, that field lets you upsert, so a rerun updates the row it loaded last time instead of creating a second one. On the historical pass you cannot upsert, so the external ID earns its place differently: it identifies exactly the set you just inserted, which makes the rollback a targeted delete of known keys rather than a guess at which records were yours. Either way the failed-load path is a retry rather than an investigation, and without the field your only rollback is a broad delete, which carries its own consequences for related records.

Automation needs an explicit position too. Validation rules, record-triggered flows, duplicate rules, assignment rules and triggers will all fire against migrated rows unless something stops them. Decide which are suspended, which stay on because they are doing work you want, and how you prove the suspended ones came back. Where the design recorded those automation choices is covered in the document that fixes the data model before loading.

Rehearsal in a sandbox produces the only honest duration estimate

Every migration plan contains a duration. Most are guesses dressed as estimates.

Salesforce’s own advice on sharing volumes makes the point for the whole exercise: test the change in a sandbox before production, because that testing gives you a baseline for how long the change will take. Nothing else does. Row counts do not predict load time, because the variables are sharing recalculation, automation, indexes and your own transformation step.

Rehearse at production-representative volume, not at a sample. Timings taken from a few thousand rows do not scale linearly to millions, because the costs that dominate at volume, sharing recalculation and automation among them, barely register on a small set. Which sandbox type can actually hold that volume is a planning constraint in itself, covered in how environments and their data get planned, and the rehearsal result is what makes the cutover timings in the go-live sequence it feeds defensible rather than optimistic.

Record two numbers from the rehearsal: elapsed time per object, and error rate per object. The second predicts your cutover more accurately than the first, because errors are what turn a timed sequence into an unplanned debugging session. Keeping both numbers against the objects named in the design, rather than in a separate tracker, is part of why GetGenerative.ai holds the migration sequence in the same project context as the data model.

Validation operates at three levels, and only one of them is a row count

Validation is where migration plans are thinnest, usually offering a single reconciliation count per object. Counts are necessary and they are the weakest of the three checks.

Counts. Source rows in, target rows created, rejects accounted for. A migration where rows in and rows out agree and nothing is explained is not reconciled, it is coincidental.

Relationships. Child records attached to the correct parent, lookups resolving to the intended target, orphan counts at zero or at a documented number. This catches the most damaging class of failure, because records that exist but hang off the wrong parent pass a count check and produce wrong reports forever.

Fidelity. A sampled field-level comparison on the fields the business actually uses, including the date fields above. Pick the sample deliberately: the oldest records, the largest accounts, anything with unusual characters, anything that went through a transformation rule.

Business sign-off attaches to the third level, because that is the only one users can judge. How that acceptance gets run and evidenced sits in the cycle that produces the sign-off evidence.

Agents read migrated records, which changes what a data defect costs

Worth adding to any plan written now, because it was not true a few years ago.

Migrated data no longer just populates reports and list views. It grounds agent responses. An agent retrieving customer history answers from whatever rows the migration produced, and it answers with the same confident phrasing whether those rows are right or wrong. A duplicate account that a human would notice and work around becomes, through an agent, two different confident answers to the same question.

This raises the value of the relationship and fidelity checks specifically. Duplicates, mis-parented children and empty fields that used to be mild annoyances now surface in natural language to someone outside your organization. Migration quality has become a customer-facing property, which is an argument for loading deliberately rather than loading everything. Legacy rows nobody will ever read are now legacy rows an agent might. The policies that govern what agents may ground on are covered in the rules that keep agent answers honest.

Where AI earns its place in a migration, and where it does not

Two tasks in this process suit a language model well, and one commonly proposed use does not.

Field mapping proposals. Given a source schema and a target object, a model produces a first-pass mapping with transformation suggestions far faster than a human, and every line is checkable against both schemas. Treat the output as a draft for review, which is also how you get mapping documentation written as a byproduct rather than afterwards.

Fuzzy matching and duplicate detection. This is the strongest fit, because it is a language problem. Deciding whether Acme Corp, ACME Corporation and Acme Corp. are one company is exactly the judgment that deterministic matching rules handle badly and natural language processing handles well, and the same applies to addresses, person names with varying transliteration, and free-text fields that need classifying into picklist values. Run it before the load, not after, since merging in Salesforce is more expensive than not creating the duplicate.

Worth naming where this sits in a delivery model rather than a toolchain. Migration planning suffers from a handoff problem, because the people who set the data model are rarely the people writing the load sequence, and the model usually reaches them as a diagram with its constraints stripped off. GetGenerative.ai removes that gap by holding one project context across its agents, so the Design Agent’s data model carries the relationships that dictate load order, the Metadata and Build Agents work against that same model, and the Testing Agent generates the reconciliation checks from it. Load order stops being reconstructed from a schema export. You can see how a migration gets scoped and staffed if that is the shape of help you need.

Not reconciliation. Do not ask a model whether the migration succeeded. Reconciliation is arithmetic against two systems of record, and it needs a query returning a number you can check, not an assessment. A model that summarizes a reconciliation report is useful; a model that produces the verdict has introduced a judgment where a count belongs.

A note on who is searching for this, since it shapes what the page owes them. Google Trends data for the year ending October 2026 puts the term salesforce data migration at its yearly high in early May. Its leading related queries are prepositional variants, data migration to salesforce and data migration in salesforce, and migration services draws more interest than migration tools. Readers arriving here are closer to needing the work done than to comparing utilities.

What a validated migration lets you sign

A plan that handles the above produces something a sponsor can approve rather than hope about.

Audit field strategy decided and exercised before the real load. Load user and ownership model set deliberately, with reassignment planned as its own operation. Sharing deferral requested early if volumes need it. Load order derived from the object graph, every object carrying an external ID so any pass can run twice. A rehearsal at representative volume giving real durations and real error rates. Three levels of validation with the fidelity sample chosen by someone who knows the business. Automation suspended and provably restored.

That package is what makes a migration a precondition for go-live rather than a risk to it, and it is the evidence set GetGenerative.ai’s Testing Agent is built to produce rather than assemble by hand afterwards. The sequencing of the wider cutover around it sits in the plan that carries the whole phase.

Questions worth settling before the first load

What are the steps in a Salesforce data migration plan?

Decide the audit field strategy, set the load user and its role position, request sharing deferral if volumes need it, derive load order from the object graph with parents before children, put an external ID on every object so passes are repeatable, suspend and later restore automation, rehearse at representative volume, load, then validate on counts, relationships and sampled field fidelity before sign-off.

Can you change CreatedDate in Salesforce after loading records?

No. Create Audit Fields allows CreatedById, CreatedDate, LastModifiedById and LastModifiedDate to be set on create only, not on update. Salesforce states that where records already exist, they have to be exported to CSV, deleted, and imported again as new records. The feature also works for insert rather than upsert, and setting these fields requires Modify All Data.

Why do migrated Salesforce activities show the wrong dates?

Two documented cases survive even with Create Audit Fields enabled. Tasks inserted with a WhoID association to a Contact or Lead, or a WhatID association to records such as Account, Opportunity or Campaign, do not reflect the supplied LastModifiedDate and LastModifiedBy. And with Enhanced Email enabled, Task records auto-created when EmailMessages are inserted carry the date of insertion rather than the EmailMessage CreatedDate.

How do you avoid ownership skew during a data migration?

Ownership skew is one user, role or group owning many records on an object, and Salesforce recommends an owner-to-record ratio of 1:10,000. Above 10,000 records for a single owner, the guidance is that the owner’s user record should not hold a role in the role hierarchy, or if it must, that the role sits at the top of the hierarchy in its own branch. Decide the load user before loading and plan owner reassignment as a separate operation.

How long does a Salesforce data migration take?

The only defensible answer comes from rehearsing at production-representative volume in a sandbox, which Salesforce recommends specifically because it gives a baseline for how long the change will take. Row counts alone do not predict duration, since sharing recalculation, automation and transformation dominate it. Record elapsed time and error rate per object from the rehearsal.

How do you validate a Salesforce data migration?

At three levels. Counts, with rows in, rows created and rejects all accounted for. Relationships, confirming children attach to the right parents and lookups resolve, since mis-parented records pass a count check. And sampled field-level fidelity on the fields the business uses, which is the level business sign-off should attach to.

Most Salesforce statements of work are assembled from a template somebody downloaded, adjusted once, and has reused since. They are usually weaker than they need to be, and the quickest way to see where is to read the contract Salesforce itself signs.

Salesforce publishes its Professional Services Agreement. It is the terms under which Salesforce sells implementation and advisory work to its own customers, and it is specific in exactly the places partner SOWs are vague.

Salesforce publishes the contract it uses, and it protects the supplier carefully

The Professional Services Agreement is linked from Salesforce’s own customer agreements page and was last updated on March 8, 2024. It governs the purchase and receipt of Salesforce professional services, and it binds a customer on either a click-through acceptance or the execution of a statement of work or order form that references it.

Read it as a benchmark rather than as a template to copy. Salesforce is the supplier in that document, so every clause is drafted from the supplier’s side, which is the side a partner SOW is written from too.

Five of its provisions are worth comparing against whatever SOW you are currently sending out. Each one closes a gap that costs partners money, and in every case Salesforce has written the protective version while most partner templates have the loose version.

Client delay is a billable event in Salesforce’s own agreement

Start with the clause that recovers the most margin, because it is the one almost no partner SOW contains.

Section 3.2 of the agreement, headed Delays, reads: if SFDC is unable to perform the Professional Services due to a Customer delay, including failure to comply with Section 3.1, Customer may be responsible for additional resource fees.

That sentence does two things at once. It establishes that a client-caused delay has a cost, and it ties that cost to a specific list of client obligations rather than to a judgment call about whose fault something was.

Compare the usual partner equivalent, which is a line in the assumptions saying the client will provide timely access to stakeholders. That is a hope. It has no consequence attached, so when the client takes three weeks to approve a sharing model, the partner absorbs three weeks and reports it as project slippage. The approval delay that caused it never appears in a commercial conversation.

What makes the Salesforce version work is that the obligations it refers back to are enumerated. Which brings us to the next clause.

Customer obligations are enumerated, not assumed

Section 3.1 lists what the customer must do, in three named groups, and the specificity is the point.

On resources, the customer assigns an internal project manager as primary point of contact for each project and allocates sufficient resources to meet its obligations under each SOW.

On actions, the customer promptly responds to inquiries, provides accurate information, data and feedback as necessary, actively participates in scheduled meetings, and where the project requires it, provides appropriate administrative access to the customer’s Salesforce account.

On facilities, the customer provides at no charge office workspace, access to other facilities where needed, and suitably configured computer equipment with Internet access.

Three details in that list reward attention. A named internal project manager is a single point of contact, which removes the commonest cause of stalled decisions. Administrative access is called out explicitly, because a project cannot proceed without it and asking later turns into a security conversation. And at no charge forecloses an argument nobody wants to have about who pays for a desk.

So the obligations section is not boilerplate. It is the thing the delay clause points at, and a delay clause with nothing specific behind it cannot be invoked. Where these obligations come from in the first place is the planning question, and they belong in the plan as dated commitments as well as in the contract, which is covered in the plan that carries them.

A time-and-materials number is an estimate, and the contract says so

This is the clause partners most often get wrong, and Salesforce’s wording is worth reading twice.

Under Section 5.1, professional services are provided on either a time-and-materials or fixed fee basis. Then the qualification: any amount set forth in a time-and-materials SOW is solely a good-faith estimate for the customer’s budgeting and Salesforce’s resource-scheduling purposes, and is not a guarantee that the work will be completed for that amount. The actual amount may be higher or lower. If the estimated amount is expended, Salesforce will continue to provide the services under the same rates and terms.

Three things are happening in that passage.

That number gets labeled. Calling it a good-faith estimate, and saying what it is for, removes the ambiguity that lets a client treat a T&M figure as a cap.

Direction is left open. “Higher or lower” is a fairer framing than a one-way warning, and it is harder to argue with.

And the overrun behavior is pre-agreed. Work continues at the same rates rather than stopping for a renegotiation, which is the clause that prevents a project pausing at the worst possible moment.

A partner SOW that states a T&M figure without this qualification has effectively written a fixed-price contract and called it time and materials. Which pricing model to choose in the first place is a separate decision with its own risk trade-offs, set out in choosing between fixed price, time and materials and outcome-based, and the estimate feeding either one comes from the method that makes a number defensible.

GetGenerative.ai supplies the scope the clauses attach to

Clause quality has a prerequisite that gets skipped, and it is not legal.

A change control clause can only be invoked against a baseline. An acceptance clause can only be tested against stated criteria. A delay clause can only be triggered against enumerated obligations. Every protective provision above depends on a scope statement precise enough to be compared with something, and that scope is usually written last, by whoever is assembling the document, from material that has not been structured.

GetGenerative.ai addresses that upstream half. Discovery output arrives structured rather than as notes, then carries into stories and acceptance criteria in one format. That gives a scope section built from recorded decisions instead of recollection. Reading the org directly matters here too, because a scope statement that names objects and fields which actually exist is harder to dispute than one describing a design assumption.

What it does not do is decide the commercial posture. How hard to press on a delay clause with a client you want a second project from, whether to cap expenses, what acceptance period to offer: those are relationship judgments, and they belong to whoever owns the account. Teams structuring presales this way can see what the platform costs to run.

Change orders require a signature before the work, not after

Section 4.2 is short and the sequencing is the whole clause: changes to an SOW require a written change order signed by the parties prior to implementation of the changes. It names what such changes may cover, including scope of work and any corresponding changes to estimated fees and schedule.

Prior to implementation is the operative phrase. A failure mode it prevents is familiar on every project that has ever run hot. Somebody agrees verbally that a small addition is fine, the team builds it, and the paperwork follows weeks later into a conversation where the client has already received the thing they are being asked to pay for.

Two additions make the clause usable rather than decorative.

Name who may sign. A change order clause that does not identify the authorized signatory on each side produces change orders signed by people whose authority is later questioned.

State what happens to the schedule. Salesforce’s version ties scope changes to corresponding changes in fees and schedule in the same sentence, which stops a client accepting the cost of a change while treating the original date as unaffected. How the date actually moves is a separate calculation, covered in what changes a go-live date.

Expenses need an estimate that only the client can raise

A small clause that resolves an annoying argument.

Section 5.2 has the customer reimburse reasonable travel and out-of-pocket expenses, and then adds the symmetry: if an estimate of incidental expenses is provided in the SOW, Salesforce will not exceed that estimate without the written consent of the customer.

That construction is better than either alternative. Expenses with no estimate invite dispute over every invoice. Expenses with a hard cap mean the supplier eats overruns caused by client-requested travel. An estimate that cannot be exceeded without written consent keeps the client in control of their own costs while leaving the supplier a route to raise them legitimately.

Payment terms sit alongside it. Invoiced amounts fall due net 30 days from the invoice date, which is worth stating explicitly in any SOW rather than leaving to a purchase order someone raises later.

The template holds twelve sections and four carry the commercial risk

With those clauses understood, the structure follows. Twelve sections, conventionally named, and unevenly weighted.

That deliverables row carries more weight than it looks. Salesforce’s agreement defines a deliverable as any output of the professional services identified as a deliverable under an SOW, which means something only becomes a contractual deliverable if the SOW says so. Listing a document in a project plan does not make it one.

Out of scope and client obligations do the work that the assumptions section is usually asked to do and cannot. An assumption is a statement about the world. A client obligation is a commitment by a party. Where the scope itself comes from is covered in the document that fixes it before design.

Salesforce-specific clauses a generic SOW leaves out

A general-purpose services SOW has no field for the things that most often cause disputes on this platform.

Sandbox and environment provision. Which environments the client provides, at which tier, and who pays if an extra one is needed. Entitlement varies by edition and an unplanned sandbox is a purchase.

Data migration scope expressed in objects and passes. “Migrate legacy data” is unpriceable. Named objects, a record volume range, and a stated number of load cycles is a scope. Anything beyond that count is a change order.

Integration endpoints and failure handling. Each interface named, with direction, frequency and what happens on failure. That last one gets omitted most often, and its absence is what turns a failed sync into an argument about whose job it was.

Release window acknowledgement. Salesforce ships three major releases a year and sandboxes move ahead of production. A project spanning a release should say so, and say who absorbs any remediation it causes.

Agent consumption assumptions. Where the scope includes Agentforce, the SOW needs a stated interaction volume and a repricing trigger. Agent work carries a run cost that moves with usage after the build is finished, so a fixed-price agent engagement with no volume assumption transfers an open-ended cost to the supplier. The configure-or-build-or-agent decision behind that scope is covered in the disposition behind that scope line.

Acceptance is the clause that decides when you get paid

Acceptance language is where SOWs are weakest, because it is the clause nobody expects to need.

Salesforce’s agreement does not supply one. Section 4.1 commits only to providing the services and any deliverables in accordance with the agreement and the applicable SOW, which pushes the whole question of when something counts as accepted into the SOW itself. On this clause the benchmark offers no wording to borrow, only the instruction that you have to write it.

Three elements make it function.

A test against stated criteria, not a judgment of satisfaction. Acceptance measured against the criteria in the deliverable is testable; acceptance measured against whether the client is happy is not. Where those criteria are produced and signed off is covered in the cycle that generates the evidence.

A review period with a defined length. Five business days, ten, whatever suits the deliverable. Without one, a deliverable sits unaccepted indefinitely and the payment attached to it sits with it.

Deemed acceptance on silence. If no written rejection with reasons arrives within the review period, the deliverable is accepted. This is the single most valuable sentence in a partner SOW and the one most often missing, because without it a client who simply does not respond has an unlimited free option.

Rejection should require reasons tied to the criteria. A rejection that says it is not what we wanted, with no reference to the stated criteria, is a change request wearing a rejection’s clothes, and the SOW should say which one it is.

Where a Salesforce SOW leaks money

Five patterns, each traceable to a clause that was present but weak rather than absent.

Row two is the most expensive over a year of projects, and it is also the cheapest to fix. Moving three sentences from the assumptions section into a client obligations section, and adding the consequence clause Salesforce uses, changes what happens in every subsequent delay conversation. Where this document sits in the wider sales motion is covered in the presales sequence that produces it.

Questions that come up when the SOW is drafted

What should a Salesforce SOW include?

Twelve sections: parties and term, background and objectives, scope of services, out of scope, deliverables, assumptions, client obligations, pricing and payment, change control, acceptance, expenses, and termination with liability. Four carry the commercial risk: scope, out of scope, deliverables and client obligations.

Does Salesforce publish a statement of work template?

Not a template, but something more useful. Salesforce publishes the Professional Services Agreement under which it sells its own implementation and advisory work, and that agreement is triggered by executing an SOW referencing it. Reading it shows how the supplier side is drafted when the supplier is Salesforce.

What is the difference between assumptions and client obligations in an SOW?

An assumption is a statement about conditions you believe to be true. A client obligation is a commitment by the client, which can be relied on and enforced. Salesforce enumerates obligations including a named internal project manager, prompt responses, participation in scheduled meetings, administrative access, and facilities at no charge, then states separately that customer delay may make the customer responsible for additional resource fees.

How should a time-and-materials SOW describe its value?

As an estimate, explicitly. Salesforce’s agreement calls the amount in a time-and-materials SOW solely a good-faith estimate for budgeting and resource scheduling, states that it is not a guarantee the work will be completed for that amount and that the actual amount may be higher or lower, and provides that if the estimate is expended the services continue at the same rates and terms. A figure without that language functions as a cap.

What does deemed acceptance mean in an SOW?

That a deliverable is treated as accepted if the client does not issue a written rejection with reasons within a stated review period. Without it, an unresponsive client holds an unlimited free option over both the deliverable and any payment linked to it. Rejections should be required to reference the stated acceptance criteria.

What Salesforce-specific clauses does a generic SOW template miss?

Environment provision and who pays for additional sandboxes, data migration scoped by named objects and a number of load passes, integration endpoints with direction and failure handling, acknowledgement that a project spanning a Salesforce release may need remediation, and for Agentforce scope, a stated interaction volume with a repricing trigger because agent run cost moves with usage.