The work, and what it changed.

Seven problems solved in production, across integration, contracts, data, Salesforce and AI. Each shows what was broken, how it was fixed and what changed. If one sounds like your company, start the conversation there.

Warehouse metrics, live inside the CRM

Account teams could not see what customers did on the platform. Warehouse metrics now land on every Salesforce account each hour and match the BI team’s official figures.

Systems integration with Snowflake, Salesforce and BI

Talk to us about warehouse data in your CRM

Replay the day the sync stalled

Normal

Rows arrive every hour and the count matches the warehouse.

Permission dropped

A warehouse permission is removed upstream. The sync stops receiving rows and still reports no errors.

Drift check fires

The hourly count stops matching. An alert reaches the owner the same day.

Caught up

The permission is restored and every missed row is loaded from where the sync stopped.

One set of numbers

BICRMStorefront
One agreed definitionThe CRM shows the official figures

Before the work, each system counted the same activity its own way.

How the sync signs in

  1. Integration-only licenceNo person’s login behind the sync
  2. Certificate sign-inNo stored password to leak
  3. Access scoped to customer accountsAnd no delete rights at all
How it was done

The problem

Account teams were making renewal and upsell calls without seeing what customers did on the platform. The numbers lived in the warehouse and the people lived in Salesforce, while BI, the CRM and the storefront each produced a different count of the same activity.

What we did

Built a Snowflake-to-Salesforce pipeline on an integration-only licence with certificate-based authentication and sharing scoped to customer accounts, so the pipeline never held delete rights. Agreed every metric definition with the BI team first, then reproduced their official figures exactly before shipping. Added drift checks so a silent stall surfaces the same day.

Signed contracts turned into reportable data

Nobody could say which customers had signed which version of the terms. Every signed contract was read, and the terms now sit on each account as fields the business can report on.

Revenue & contract operations with DocuSign, Salesforce and Legal

Talk to us about reportable contracts

From a clause in the PDF to a field on the account

Signed order form, page 2
Account record
Contract term
24 months
Platform fee
$1,200 a month
Notice period
60 days
Terms version
2026 standard

Example contract with invented terms. Pick a clause to see the field it becomes.

What changed

AreaBeforeAfter
Who signed which termsNobody could say without opening PDFsOne report answers it
New terms rolloutEvery customer assumed to need new paperOnly the accounts Legal’s rules require

Then the contract workflow

  1. Clause library owned by LegalPre-approved wording, kept current by Legal
  2. Approval routing by clauseEach clause carries its approver
  3. Contracts generated from the dealSent for signature without retyping
How it was done

The problem

Legal changed the standard terms and nobody could say which customers had signed which version. The answer lived in years of signed PDFs, not in any field the business could report on.

What we did

Read every signed agreement at the document level with a reviewer-and-challenger process, encoded Legal’s rulings as rules and loaded the result as structured terms on each account. Then built a governed contract workflow: a Legal-owned clause library, approval routing by clause and DocuSign generation straight from deal data.

A new sales process for every live deal, in one evening

Leadership wanted five stages with exit criteria. Every open deal moved in one evening, and the reports leadership reads each week kept their history.

Salesforce engineering with Salesforce and Reporting

Talk to us about changing your sales process

Where each old stage went

Old stages
New stages
DiscoveryExit criteria checked before moving on
Solution valueExit criteria checked before moving on
ProposalExit criteria checked before moving on
Contract sentExit criteria checked before moving on
ClosedExit criteria checked before moving on

Pick an old stage. Salesforce’s default stage names are shown; the new names are generalised.

Before the move

  1. Every report and dashboard checkedFor any filter or grouping on the old stages
  2. The affected ones re-pointed firstSo leadership numbers stayed continuous

The migration evening

  1. Rehearsed in a full-copy sandboxAt production volume
  2. Pre-image savedEvery deal and its stage history
  3. Every open deal moved in one eveningWith no failed records
  4. History and dates preservedReports read the same the next morning
How it was done

The problem

Leadership wanted a five-stage process with exit criteria enforced at each step. Every open deal, a large report library and the numbers leadership reviewed each week all depended on the old stages.

What we did

Swept every report and dashboard for references to the old stages, rehearsed the move in a full sandbox and migrated with a pre-image of every deal and its stage history. Exit criteria went in as validation at the stage where the data is needed.

One record per customer, across two regions and three platforms

Customers existed twice, once per region. Each now has one record, with both regions’ storefront IDs, owners and terms side by side.

Data unification with Salesforce, Adobe Commerce and Snowflake

Talk to us about merging duplicate customers

Two regional records become one

Customer, North America
Storefront ID
NA-30417
Owner
Priya Raman
Terms
North America
Customer, Europe
Storefront ID
EU-11802
Owner
Lukas Brandt
Terms
Europe
Merged in rehearsed waves, no data lost
Customer
Storefront IDs
NA-30417 and EU-11802
Owners
Priya Raman, Lukas Brandt
Terms
Both regions, side by side

Example record with invented values.

Proved before production

  1. Every wave rehearsed at full volumeIn a sandbox, before production
  2. A pre-image kept for every recordSo any merge could be reversed
  3. Storefront IDs checked at the sourceAgainst the commerce platform’s own API

Caught by the premortem

  1. Currency fields would have relabelled euros as dollars.
  2. Middleware rewrote merge targets after the merge.
  3. Other showstoppers, each fixed before the first wave.
How it was done

The problem

Customers existed twice, once for North America and once for Europe, with storefront IDs, owners and contract fields split between the two. Every regional report needed manual reconciliation.

What we did

Ran a premortem before any merge, which caught showstoppers including currency fields that would have relabelled euros as dollars and middleware that rewrote merge targets. Rehearsed every wave at full volume in a sandbox, kept a pre-image of every record, then reconciled regional storefront IDs against the commerce platform’s own API.

Revenue leaks closed between the deal and the bill

Money leaked between the signed deal and the bill. Each leak was traced to its cause on real records, fixed at the rule and backfilled.

Revenue protection with Salesforce, DocuSign and Billing

Talk to us about revenue leaks

Where the money leaked

Deals nobody had touched in years

Surfaced for review, with a preview before anything closed.

Set-up fees dropped on the way to billing

Restored on every open deal and fixed at the rule.

Billing contacts wiped on save

Protected, and the save that wiped them fixed.

Renewal dates drifting

Reconciled to the signed contracts.

What changed

AreaBeforeAfter
PipelineInflated by deals nobody ownedOnly deals someone is working
Renewal datesDrifting away from the contractMatching the signed contract

How each leak was closed

  1. Reproduce on real recordsFind the rule that causes the leak
  2. Fix the ruleSo the leak cannot recur
  3. Backfill with a change fileEvery changed value recorded
How it was done

The problem

Set-up fees vanished between the signed deal and the billing record. Renewal dates drifted. Billing contacts were silently wiped. Pipeline carried deals nobody had touched in years.

What we did

Traced each leak to its mechanism with a reproduction on real records, fixed it at the rule and backfilled with a file that records exactly what changed. Built an expiry engine that previews every deal before it closes anything.

AI prospecting a sales team can trust

An AI prospecting tool kept returning customers the CRM already had. The identity layer it checks against now covers every known prospect.

AI readiness with AWS, Salesforce and Apollo

Talk to us about AI prospecting

Where the identity check sits

AI prospecting toolFinds companies that look like good prospects
Identity registryEvery known customer and prospect, across all their domains
Fail-fast guardStops the run if the registry ever loads empty
Sales booksOnly real net-new prospects, graded

What changed

AreaBeforeAfter
Leads called net-newMostly companies the CRM already hadExisting customers recognised, real prospects surfaced
Trust in the outputVendor accuracy taken on faithCost and accuracy measured on hand-checked samples

How it was rolled out

  1. Check a sample by handBefore any rollout
  2. Report cost and accuracyTo leadership, in plain terms
  3. Roll out book by bookTo each sales team in turn
How it was done

The problem

An AI prospecting tool promised net-new leads. Most of them already existed in the CRM, because the registry it checked against covered only a small share of known prospects.

What we did

Rebuilt the identity layer the AI checked against, widened it to every prospect in the CRM across multiple domains per company and added a fail-fast guard for when the registry loads empty. Measured cost and accuracy by hand-checking samples before each rollout, and reported both to leadership.

A decade of org debt, retired without an outage

Ten years of automations, profiles and stored history had piled up. The org was simplified without an outage or a locked-out user.

Platform health with Salesforce

Talk to us about an org health check

What changed

AreaBeforeAfter
AutomationsSeveral racing on the same objectOne governed pattern per object
Workflow rulesLegacy rules facing platform retirementRetired ahead of the deadline
Security profilesDozens, each a slight variationConsolidated, with every user checked first
Data storageOver the limit, failing integration insertsBack under the limit within a day
How it was done

The problem

Racing automations on core objects, legacy workflow rules facing retirement, dozens of security profiles and a storage limit that had started to fail integration inserts.

What we did

Mapped every automation per object and consolidated to one governed pattern, retired dead reports on usage evidence, checked every permission change against every user before it shipped, and archived history to bring storage back under the limit in a day.

Start with the problem that sounds most like yours.

Tell us which systems are involved and what is going wrong. We reply within one business day, and new engagements begin in January 2027.

hello@feldtgroup.com