A sales opportunity is marked won. The delivery team still asks for the scope by email. Finance creates the customer again. Someone maintains a spreadsheet to explain what has actually started.
It is tempting to put “rebuild Salesforce” at the top of the project brief. First, find out which part of that journey is failing.
A rebuild may be justified. So might a smaller change to responsibilities, data, configuration or an integration. Tracing a real piece of work gives you a basis for comparing those options.
Start with a piece of work, not a feature list
Choose a recent example that caused friction: an order that stalled, a customer handover that needed chasing, or a service request that bounced between teams.
Agree where the workflow starts and what “finished” means. “Opportunity won” and “delivery ready to begin” are different milestones. Record the information, decisions and people between them.
Walk through it with the people who do the work. Ask them to show what happened, including emails and spreadsheets used alongside Salesforce. Use authorised records and minimise customer details in anything you share.
Salesforce’s business-analysis guidance emphasises understanding users, requirements and business activities before choosing improvements. The worksheet below turns that principle into a starting point for your own discussion.
Use this workflow trace
Copy these questions into a document. Add a row whenever responsibility passes to another person or system.
| Question | What to capture |
|---|---|
| What starts this step? | The actual event or decision, not just the screen someone opens. |
| What should happen next? | A specific result and the person or team responsible for it. |
| What information is needed? | Required details, where they come from and which system owns updates. |
| What actually happened? | A record reference, timestamp or observation that can be checked. |
| What happens when it fails? | Who notices, who acts and how they know the problem is resolved. |
Start with one troublesome example, then compare it with a successful one and other relevant cases. One record can reveal a question worth investigating; it cannot establish how often a problem occurs.
Four places to investigate
Treat these as overlapping possibilities, not a test that automatically diagnoses your system.
1. Process: does anyone own the next step?
A record can be complete and technically correct while the work waits for an unassigned decision.
Look for unclear handover criteria, competing definitions of “ready”, or a queue that everyone can see but nobody owns. Ask who accepts the work and what they need before they can proceed.
A useful next step may be agreeing responsibility and acceptance criteria, then deciding whether Salesforce should make them visible.
2. Data: do the teams mean the same thing?
Two systems can both have a “customer status” field and use it differently.
Check definitions, required information, identifiers and the agreed source for updates. Compare the underlying records before treating a reporting mismatch as a reporting-tool problem.
For example, sales may call an account “active” after a contract is signed, while delivery uses “active” only after onboarding. That needs an explicit definition or separate milestones; synchronising the same label does not resolve the disagreement.
3. Configuration: does the setup support the agreed process?
Where people agree on the process and the information is available, ask a Salesforce specialist to examine how the setup behaves.
Relevant areas might include access, validation, automation, record layouts or routing. Identify the condition under which the behaviour changes rather than assuming that every manual step needs another automation.
Salesforce’s record-triggered Flow guidance recommends analysing and validating the process with stakeholders before building. Any proposed configuration change still needs testing against the organisation’s existing automation and access requirements.
4. Integration: can you follow the work across systems?
A visible change in Salesforce does not, by itself, establish that another system completed its part.
Ask the technical owner what evidence exists on each side: identifiers, acknowledgements, errors and the expected timing of the transfer. If a request is repeated, can the receiving system recognise it without creating duplicate work?
Salesforce’s integration patterns discuss error recovery and safe handling of repeated requests. The appropriate approach depends on the integration. Do not replay failed transactions in a live system simply to find out what happens.
An illustrative sales-to-delivery handover
Imagine a consulting team where closing an opportunity should hand work to a delivery coordinator. This is a hypothetical example, not a Komet client result.
The opportunity is won and a project record appears. Delivery still cannot start because the agreed scope is held in an email attachment and nobody has accepted ownership of the handover.
The initial complaint is “the integration doesn’t work”. The trace suggests two different questions:
- Was the project created with the intended information?
- Was someone responsible for confirming that delivery had everything needed?
The first needs a technical check. The second needs an operating decision. A rebuild proposal should explain how it would address each, and what a narrower repair could achieve.
When should a rebuild stay on the table?
A workflow trace is a starting point, not a complete architecture assessment. Broader redesign may warrant investigation when several critical workflows share structural constraints, the data model no longer fits the business, or specialists identify significant supportability or security concerns.
Compare a targeted repair with a phased redesign or rebuild. For each option, ask:
- Which observed problems will it address, and what will remain?
- What evidence supports the proposed scope?
- What dependencies, migration work and disruption are involved?
- How will users test the result, and who will maintain it?
Urgent security or operational incidents need the appropriate response immediately; they should not wait for this exercise.
Define the result before commissioning the work
“Improve Salesforce” is difficult to test. “Delivery can accept a handover with its required information and named owner” gives the team something concrete to assess.
Choose measures that fit the workflow: time waiting for acceptance, missing-information cases or manual re-entry, for example. Establish a baseline and agree how to collect it. Set targets from your actual situation rather than adopting a universal benchmark.
Have a workflow that keeps needing workarounds? Contact Komet with a short description of where it stalls and what a better outcome would look like. Keep customer records and sensitive details out of the initial enquiry.