Case Study · Systems Recovery + Process Design

Salesforce Request Form Rebuild

Replaced an undocumented, email-driven intake process with a governed Salesforce request form that sequences work instead of blocking on it — cutting a roughly month-long process down to days.

Oracle → Salesforce Governed intake Hard / soft stops Team-owned

Details are generalized; sensitive identifiers and client specifics are redacted.

The problem

A manufacturing process was moving from Oracle to Salesforce with no documented intake process behind it, just email.

Requests were tracked through back-and-forth Outlook threads, not a system.
Leadership's fix in progress was a set of redundant Excel sheets and archive folders: one more copy for every new request type.
That approach was ungoverned and insecure, and it would have recreated the same problem the moment a new request type showed up.

The solution

A single, governed request form in Salesforce that sequences the work instead of demanding every answer up front.

Pulls data directly from Salesforce and shared drives instead of manual re-entry.
Hard stops where the process genuinely cannot proceed without an answer; soft stops where it can, with the field auto-populating once the information lands.
Transparent handoffs so the right person gets the right information at the right time, instead of waiting on a single upfront intake.

Hard stops vs. soft stops

Hard stop: the request cannot move forward without this; the form blocks submission until it's answered.
Soft stop: the request can proceed now; the field auto-populates once the information becomes available elsewhere in the system.
Splitting these apart meant teams stopped waiting on information they didn't need yet just to start work they could do today.

Sourced data, transparent handoffs

Fields pull from Salesforce and shared drives directly, instead of asking requesters to re-key what already exists somewhere.
Each handoff point is visible: who owns the request next, and what they're waiting on to act.
Work can run in parallel across owners instead of queuing behind a single upfront intake.

Before

~1 month

Typical request cycle time under the email-driven, ungoverned process.

After

Days

Cycle time once work could run in parallel instead of waiting on a single upfront intake.

Workaround removed

Redundant Excel sheets and archive folders left in place after the rebuild.

Summary

Replaced an email-based intake process with a governed Salesforce request form, cutting the process from roughly a month to a few days.

Eliminated the redundant Excel sheets and archive folders that leadership had been using to patch the gap, closing an insecure, ungoverned workaround.
Reduced the request cycle from about a month to a few days by letting work start in parallel instead of waiting on a single upfront intake.
Unblocked product releases that had been delayed by paperwork bottlenecks, not engineering work.

Request details →

They started changing it right away

The team didn't just operate the form: they extended it, using this build as a template to create request forms for new use cases on their own.
They added and removed fields as their needs changed, without needing us back in the system.
They enhanced the soft-stop logic themselves as they found new places it could help.

Documentation that stayed alive

Delivery included a modular knowledge base, not a one-time handoff document.
The team has kept it updated and maintained since, which is the actual signal that ownership transferred.
Every engagement aims at the same finish line: something the client can run and evolve whether or not they ever need to call us again.

“Delivering your vision that your team can actually own.”

↑ Back to top

Salesforce Request Form Rebuild

What was actually happening, and what we built instead

Sequenced, not linear

Scannable summary

What the team did with it after we left