What Does a Salesforce Consultant Actually Do?
A Salesforce consultant solves business problems, and Salesforce happens to be the tool. That's the short answer.
The longer answer is messier. People picture someone clicking through setup screens and building dashboards. That's part of it. But most of the job is figuring out what a business actually needs, saying what it will cost, and making sure the thing still works six months after go-live.
Here's what that looks like in practice.
What a typical week looks like
No two weeks are the same, but the work falls into a few buckets.
Translating business rules into system rules. A client says "our max discount should include the dealer fee" or "count materials differently on this report." Those aren't Salesforce requests. They're how the business makes money, and the job is to make the system match.
Advising on build vs. buy. Clients regularly ask whether an AppExchange package is worth installing. A good answer compares it to what they already own, weighs who maintains it, and ends in a recommendation, not a feature list.
Managing environments and releases. Sandboxes drift out of date. Automations get built with hardcoded values that break the moment they move between orgs. A big part of the job is keeping dev, test, and production in sync, and moving changes through review and QA before they reach users.
Testing integrations end to end. Salesforce rarely lives alone. It talks to ERPs, accounting systems, payment processors, and scheduling tools. Testing each piece isn't enough; you have to prove a record created on one side becomes the right result on the other.
Designing the data model. Choosing what to call a new object and what hangs off it sounds like semantics. It decides what reporting is possible for years.
Keeping the org healthy. Unused fields pile up, users get frozen instead of deactivated, and objects creep toward their limits. Routine cleanup makes room for what the business needs next.
Protecting sensitive information. Commissions, pricing, and personal data show up everywhere in a CRM. Good consulting includes knowing what belongs in release notes and screenshots, and what doesn't.
The kinds of problems we get called in to solve
Most of the interesting work starts with a symptom that doesn't make sense. A few patterns we see again and again:
The data that keeps changing on its own. Someone enters a value, saves, and it's gone. Users assume they made a mistake and re-enter it by hand. Usually an automation is firing when it shouldn't, because a condition that looks right doesn't behave the way its author expected. The fix is often small. Finding it means reading field history, tracing every automation on the object, and proving the cause before changing anything.
The process that quietly stopped working. A scheduled job fails on one record, and the easy move is to patch that record. The better move is to ask how many others are affected and since when. Often a rule added months earlier for a good reason is blocking a process nobody was watching. Putting a number on the impact turns "a few things are failing" into a decision the client can make.
The out-of-the-box feature that's almost right. Standard features cover most needs, until they don't. Pricing that's off by a few cents, a report that can't show what the CFO wants, a quote document that needs a field the template won't allow. Solving these means knowing when to extend the platform, and building it so the next change doesn't break the first one.
The requirement that changes years later. Systems outlive the assumptions they were built on. A new division, a new regulation, or a new sales motion can make a sound design decision suddenly wrong. Long-term partners know why each decision was made, so they know which one to change and which to leave alone.
What separates a good consultant from a configurator
Anyone can learn where the buttons are. The difference shows up in a few habits.
They ask "was this intended?" Most bugs are symptoms. Real fixes start with whether the behavior was ever on purpose.
They quantify the problem. "Some records are failing" gets shrugs. A count and a date range get a decision.
They respect process. Changes go through QA and peer review before they reach production. Release notes say what changed and who it's for. Boring, and it's why clients trust a partner with their org.
They teach. The goal is a client team that understands its own org and can maintain it. A consultant who makes you dependent isn't doing the job.
They stick around. Our client relationships average more than three years. Long tenure means remembering why the weird field exists, and that memory is worth more than any certification.
How AI is changing the job
AI hasn't replaced Salesforce consultants. It has moved where our time goes: less on building, more on judgment.
The build got faster. Work that used to take a day of clicking now takes an hour of reviewing. Auditing an object, drafting a flow, documenting a deployment, mocking up a screen: AI does the first pass in minutes.
That makes "build vs. buy" a different question. When a custom solution takes days instead of months, buying a package to cover 70% of a need is harder to justify. We increasingly recommend building on Salesforce for anything specific to how a client works, and buying only commodity pieces like e-signature.
Judgment matters more, not less. AI is very good at producing a list. It is not good at knowing which items on the list matter, or what the client should actually do about them. We treat AI output as a starting point for a consultant to investigate, not a deliverable.
Clients don't want more documents. When generating a 40-page analysis costs nothing, it's tempting to send one. The value is still the answer, delivered in a form someone will actually read.
Governance is now part of the job. Connecting an AI tool to a client's production org is a security decision, and we treat it like one. Clear change management, approvals, and an audit trail of what changed and why matter more when changes happen faster.
What this means for the role. The consultant of the next few years looks less like a builder and more like an architect and editor. They frame the problem, direct the build, check the output, and own the result. The skills that were always the job (asking good questions, understanding the business, saying "no" or "not yet") are now most of it.
The short version
A Salesforce consultant's real job is to understand how your business works, make the system match it, and keep it matching as the business changes. Some weeks that means a new integration. Some weeks it means one line of code that fixes a problem everyone had learned to work around.
Krahnborn is a Madison-based Salesforce consultancy that has spent years doing this for mid-market manufacturers, distributors, and field-service companies. If your org has a problem nobody can quite explain, let's talk.