u/jcarmona86

I run a community about telling the truth, and the truth is I disappeared from it.

Not dramatically. Nothing happened. That’s almost the point. Client delivery happened. Salesforce projects happened. Operations, research, systems, file organization, work for other people’s organizations. All of it real, most of it good, and every hour of it billed to someone else’s future.

Here’s what those months actually looked like. I built validation frameworks, publishing plans, and governance pages for my own content, which sounds like writing but isn’t. Somewhere in there, the link to my own AI readiness scorecard broke, and it stayed broken for weeks before I noticed. Every visitor hit a 404. I get paid to find broken processes in other people’s orgs. My own front door was down and nobody was home to hear the knock.

Here’s what I’ve noticed about being the useful one. Nobody takes your time from you. You hand it over voluntarily, in ninety-minute increments, and each individual handoff is defensible. The client needed it. The deadline was real. The system had to ship. Then you look up and your own writing, your own community, your own name got whatever energy was left at the end, which rounds to zero.

I tell clients that an org nobody owns is a future incident. I apparently needed a few months to notice I was running my own presence the same way.

What I’m changing is small and specific. My own work goes on the calendar the way client work does, with a booked slot it can’t be bumped from. Writing here is part of that slot, starting today, weekly. I’m not promising daily posts or a content empire. I’m promising to be in the room.

The guilt is the strange part. Spending an hour on my own future still feels like stealing from someone. I don’t fully have that one figured out, so I won’t pretend to.

For the people here who are the reliable ones at work: what’s the project with your own name on it that keeps losing to everyone else’s deadlines?

There is a specific kind of tired that comes from being accountable for a decision someone else makes.

The pattern shows up the same way most times I see it. An admin or a solo architect gets named as the owner of the agent rollout. They write the topics, wire the actions, run the tests. Then somebody above them decides which objects the agent can read, on a timeline set by a launch date, and the owner finds out in the deployment thread.

Gartner put a number on where that goes. By 2027 they expect 40% of enterprises to demote or decommission autonomous agents, driven by governance gaps found after a production incident.

The gaps are not usually invisible before launch. Somebody saw them. That person did not have the standing to hold the release.

I used to treat this as an org chart problem. Bad reporting line, nothing to do about it. That was wrong. It is a design problem, and it is fixable at the permission layer rather than the political one.

What has worked: write down, per agent, which objects it can read and which it can write, then attach a named approver to the write list. Not a team. A person. When the approval requirement lives in the deployment doc, the conversation stops being about your seniority and starts being about an unsigned line.

That does not give anyone authority they were denied. It makes the absence of authority visible before the incident instead of after.

For those of you running agents in production: who signs off on scope where you work, and did that get decided on purpose or by default?

There is a specific kind of tired that comes from being accountable for a decision someone else makes.

The pattern shows up the same way most times I see it. An admin or a solo architect gets named as the owner of the agent rollout. They write the topics, wire the actions, run the tests. Then somebody above them decides which objects the agent can read, on a timeline set by a launch date, and the owner finds out in the deployment thread.

Gartner put a number on where that goes. By 2027 they expect 40% of enterprises to demote or decommission autonomous agents, driven by governance gaps found after a production incident.

The gaps are not usually invisible before launch. Somebody saw them. That person did not have the standing to hold the release.

I used to treat this as an org chart problem. Bad reporting line, nothing to do about it. That was wrong. It is a design problem, and it is fixable at the permission layer rather than the political one.

What has worked: write down, per agent, which objects it can read and which it can write, then attach a named approver to the write list. Not a team. A person. When the approval requirement lives in the deployment doc, the conversation stops being about your seniority and starts being about an unsigned line.

That does not give anyone authority they were denied. It makes the absence of authority visible before the incident instead of after.

For those of you running agents in production: who signs off on scope where you work, and did that get decided on purpose or by default?

There is a specific kind of tired that comes from being accountable for a decision someone else makes.

The pattern shows up the same way most times I see it. An admin or a solo architect gets named as the owner of the agent rollout. They write the topics, wire the actions, run the tests. Then somebody above them decides which objects the agent can read, on a timeline set by a launch date, and the owner finds out in the deployment thread.

Gartner put a number on where that goes. By 2027 they expect 40% of enterprises to demote or decommission autonomous agents, driven by governance gaps found after a production incident.

The gaps are not usually invisible before launch. Somebody saw them. That person did not have the standing to hold the release.

I used to treat this as an org chart problem. Bad reporting line, nothing to do about it. That was wrong. It is a design problem, and it is fixable at the permission layer rather than the political one.

What has worked: write down, per agent, which objects it can read and which it can write, then attach a named approver to the write list. Not a team. A person. When the approval requirement lives in the deployment doc, the conversation stops being about your seniority and starts being about an unsigned line.

That does not give anyone authority they were denied. It makes the absence of authority visible before the incident instead of after.

For those of you running agents in production: who signs off on scope where you work, and did that get decided on purpose or by default?

Asking for a friend.

Asking for a friend.

Sit with that for a second. I get paid to give an honest read on what their system needs. The feedback is that my honest read is insufficiently expensive. Nothing says strategic thinking like arriving, through careful analysis, at the conclusion that what you really need is more of me.

I did not handle this gracefully in the moment. The word had meant something to me for most of my career and it took one meeting to find out it now means quota.

The part that actually bothers me: this is the incentive that produces every org I get called in to fix. Somebody was strategic five years ago. Sold three products nobody scoped, built automation nobody documented, and left. Now I am in there cleaning it up, being told the problem is that I am not doing enough of what caused it.

Anyone else had a client define strategic for you? Curious whether I got a unique version or the standard one.

When you’re the sole Salesforce Consultant for a company who just implemented Salesforce, know that a)these are the stories that no one shares and b) consider if running your own Salesforce Consultancy solo is what you really want to do.

Hold onto your answer. It is the single best interview question in this ecosystem and almost nobody asks it.

I know it works since I failed it from the other side. Early nonprofit gig, I was the entire approval process for new fields. Development wanted a checkbox, I built the checkbox. Finance wanted a picklist with fourteen values, done before lunch. I thought I was being responsive. What I built was a monument nobody could read three years later. The person who replaced me asked which fields were still in use and I handed her a spreadsheet I had stopped updating in month four. She was polite about it.

Tara Kermiet posted four interview questions this week that get at this. They ask for a specific past event instead of a general impression. Values get rehearsed. A story you do not have cannot be.

Hers, verbatim:

**1.**	Tell me about the last time you told leadership a deadline wasn’t realistic.  
**2.**	Walk me through who has to approve a normal, boring decision.  
**3.**	When was the last time somebody took a real unplugged vacation, and who covered their work?  
**4.**	If you offered me this job tomorrow, what would you tell me to think hard about before I said yes?

Number two is the one I would build an entire interview around, and in our world it has a specific form: who approves adding a custom field?

Two answers should scare you, and they fail in opposite directions. Change advisory board plus a two-week lead time for a picklist value means you will spend year one filing tickets against yourself. “You just add it” means you are inheriting my old org. The answer worth hearing is boring: light intake, a data dictionary someone actually maintains, a person who says no often enough to be mildly disliked.

Question one translates just as cleanly. Ask when the platform team last pushed a go-live date and what happened to the person who raised it.

Then listen to the pause.

Questions three and four measure the same thing from opposite ends. Coverage and honesty. Frame three as a scenario instead of a survey: the Friday 4 PM Flow failure, walk me through the next twenty minutes. Who gets the alert. Whether the alert comes from a monitoring tool or from a VP staring at a blank dashboard. Whether the person fixing it is the same person supposedly on vacation in Portugal. One version of that answer describes a job. The other describes a pager.

Question four needs no translation. Ask it exactly as she wrote it.

Two I have added over the years, both really the same question in different clothes. When did you last retire a custom object or field? Orgs accumulate. Almost nobody prunes. A team that has run a decommission project has governance; a team that has never deleted anything has archaeology. And the quieter one: what percentage of licensed users logged in last week? Half the orgs I have walked into cannot answer that. The ones that can are the ones where adoption belongs to a named human instead of to everyone.

On reading the answers: you are not grading right or wrong. You are listening for whether a specific event comes to mind. Specificity means the thing happens. Vagueness means it does not happen, or it happens and nobody is allowed to describe it out loud.

Ask your future peers, not just the hiring manager. The manager is selling through round three. The senior admin who would sit next to you usually stopped selling somewhere in round one, which is why that conversation is the useful one.

Happy to DM the full list if it helps. Fair warning that a few of you are going to ask question two, get the “you just add it” answer, and take the job anyway. I would have too.

It’s Sunday, and I’m working.

Not because a client emergency appeared. Nothing is broken. No Flow has declared war on production. At least not yet.

I’m working because running a solo consultancy means every unfinished task eventually reports to the same person.

Me.

Client delivery. Proposals. Invoices. Content. Follow-ups. Website updates. Bookkeeping. Research. Scheduling. The work I planned to complete Friday and the work I optimistically assigned to “next week,” as though next week had not already hired me.

When I worked a traditional job, weekends felt different. There was a line between work and the rest of my life, even when that line occasionally became blurry.

Now I am the person responsible for drawing the line.
I am also the person most likely to ignore it.
People talk about starting a consulting business as though the main decision is leaving a job and becoming free.

The reality is less cinematic.

You become the architect, salesperson, project manager, support desk, marketing department, accounts receivable team, and person wondering why the website form stopped sending notifications.
Freedom is part of it.

So is waking up on Sunday thinking about a proposal, a client risk, or an idea that feels urgent only because it belongs to you.

I chose this, and I am grateful that I did.
That does not mean I want to pretend every part of it is inspiring.

Some weeks feel exciting. Some feel unstable. Some are full of meaningful client work. Others are spent fixing operational problems nobody will ever see or appreciate, which is apparently the traditional reward for running a business correctly.

I’m going to start sharing more of that here.
Not another “I quit my job and built a thriving consultancy in 30 days” story.

A real look at what it takes to start and operate a solo Salesforce consulting business:
The decisions that work.
The ones that cost me time.
How I find work.
How I price projects.
How I manage multiple clients.
What I automate.
What I still do manually.
Where AI genuinely helps.
Where it creates more cleanup.
What happens when revenue is uneven.
How I handle boundaries when the business follows me into the weekend.

I do not have every answer and that is part of the point.

I want to document the process while I am still inside it, before hindsight edits the uncertainty out and turns everything into a neat success story.

So this is the beginning.

A solo Salesforce consultancy, shown without the victory-lap versions.

I spent eight years as a journalist before I moved into Salesforce.

I covered Tuesday-night city council meetings in fluorescent-lit rooms that smelled like old coffee. I waited outside courthouses in February. I chased sources who didn’t want to talk and filed stories while editors reminded me that deadlines were, inconveniently, still real.

Then I decided to change careers.

It took me 3.5 years to land my first Salesforce job.

Not 3.5 months.

Years.

I had a journalism degree, no technical background, and kept finding “entry-level” jobs asking for two years of Salesforce experience.

The usual career-change arrangement: you need experience to get experience, and apparently you acquire the first batch through prayer.

I volunteered as a Salesforce admin for a nonprofit. I wrote about what I was learning. I applied for roles that valued communication and problem-solving, not just credentials.

For a while, I deliberately avoided certifications. I wanted to prove I could do the work before a badge told anyone I belonged.

Then COVID happened.

I earned my Admin certification in January 2021 and responded with complete moderation by earning another eleven certifications over roughly the next year and a half.

From the outside, the story looks clean.

Journalist changes careers. Earns certifications. Becomes an admin, architect, instructor, consultant, and business owner.

A tidy little transformation that didn’t feel tidy while I was living it.

The hardest part wasn’t Flow, validation rules, or SOQL. Technical skills take time, but at least Salesforce eventually tells you when the syntax is wrong.

The harder part was rebuilding how I saw myself.

For years, I introduced myself as a journalist. It wasn’t just my job. It was how I understood what I contributed.

I asked questions. I found what people were avoiding. I turned confusion into something other people could understand.

“Salesforce consultant” didn’t immediately fit that story.

During my first months in the ecosystem, I sat in discovery meetings taking notes like I was still reporting. I asked follow-up questions because that was the only professional instinct I completely trusted.

I worried everyone else understood the platform better than I did.

Some days, they did.

Other days, they were simply more confident while being equally confused. Salesforce has built a respectable economy around that distinction.

I started SF Unfiltered because too much of the Salesforce ecosystem shows people the finished profile and removes everything that happened before it.

Career changers are usually given a familiar checklist:

Get certified. Build a portfolio. Network. Apply consistently. Keep learning.

That advice can help.

It also leaves out a lot.

The rejection emails. The job descriptions expecting one person to be an admin, developer, architect, analyst, data steward, trainer, and emergency support desk.

The first time you break something and quietly wonder whether you chose the wrong career.

The months when you keep learning while everyone online appears to be passing exams, landing jobs, speaking at conferences, and achieving spiritual fulfillment through Trailhead.

Accidental admins get a different version of the same experience.

Someone notices they’re “good with systems,” gives them Salesforce, and quietly disappears.

No real training. No documentation. No authority to make the business decisions the system requires. No protected time to maintain it.

Leadership still expects accurate reports, clean data, functioning automation, secure permissions, happy users, and perhaps an AI strategy before the next steering committee meeting.

That isn’t an individual failure.

That is an operating model held together by optimism and one exhausted person’s memory.

SF Unfiltered exists so people can tell the part of the story that normally gets removed.

Maybe it’s the certification that didn’t immediately change your career.

Maybe it’s the implementation that launched but never truly worked.

Maybe it’s the Flow that taught you humility at 7:43 on a Tuesday night.

Maybe it’s the project where nobody owned the data, the job search that took years, or the moment you almost walked away because you thought everyone else had figured something out that you hadn’t.

Venting is welcome here.

Cruelty isn’t.

This isn’t a place to mock beginners, shame career changers, attack users, or turn someone’s mistake into proof that they don’t belong.

It also isn’t a vendor promotion feed, a recruiter fishing pond, or another community where every career problem is answered with “get another certification.”

The goal isn’t to hate Salesforce.

The goal is to tell the complete truth about working in it.

Salesforce can give you a real career while still frustrating you.

Experience doesn’t eliminate uncertainty. Certifications don’t prevent mistakes. Competence doesn’t mean you never feel lost again.

People who have been in the ecosystem for years should talk about those moments too.

Not because struggle is a competition.

Someone starting today deserves a more honest map than many of us received.

This community won’t always have the answer.

There will be technical fixes, career advice, project lessons, and conversations where another person simply says:

“I went through that too.”

That matters.

If you’re in year two and feeling stuck, you’re not behind. You’re in the middle.

What part of your Salesforce story usually gets edited out?

Salesforce admin burnout is not a character flaw. It is what happens when one person is expected to do support, reporting, permissions, automation cleanup, and documentation for an org that keeps adding “just one more thing.”

The job gets exhausting when:
• Requests have no priority.
• Nobody owns the process.
• Documentation is missing.
• Every “quick fix” becomes permanent.

Real fix is boring:
• Track requests.
• Push back on timelines.
• Kill bad automation.
• Make leadership choose priorities.
• Stop pretending the admin can absorb infinite chaos.

As always, thank you for coming to my TED talk.

Salesforce admin burnout is not a personality flaw. It is what happens when one person becomes the unofficial owner of every broken process, every weird report request, and every automation that was “working fine yesterday.”

If Tuesday nights make you want to stare into the middle distance and rethink your career, welcome.

You are not alone.

Quick update from your mod. I’ve been rebuilding this community from the ground up over the past few weeks, and the relaunch lands July 21.

What’s changing: a rebuilt wiki (four pages instead of nine broken ones), ten clear rules with stated enforcement, new post flair for the conversations this place is actually about (Career Reality, Tech Debt, AI / Agentforce, Project Post-Mortem), a Weekly Vent Thread every Friday, and a real posting cadence from me.

What’s not changing: the premise. Real talk about Salesforce, no corporate filter, names redacted, systems criticized instead of people.

Before I lock the rebuild: what do you want from this community that you can’t get in the bigger Salesforce subs? Serious question, and it’ll shape what goes live next week.

Internet is down and according the Spectrum App, there’s no issues. It’s been about two hours also live near S3 and Keap.

Anyone experiencing any issues?

Two things dropped this week in nonprofit tech. Both are being presented as progress. I've spent the better part of a decade implementing Salesforce for nonprofits. I have notes.

The NPSP Consultant certification is retiring.

February 1, 2027. Registration closes July 24. Last day to sit: August 31.
That's 39 days to register if you're mid-study or had this budgeted.

The replacement is the Nonprofit Cloud Consultant cert. Different product,architecture and data model. Calling it a "successor" is technically accurate the way calling a motorcycle a "successor" to a bicycle is technically accurate.

The some of the orgs I work with are still on NPSP. Some just finished migrating off spreadsheets. A handful have a dedicated Salesforce admin.
Most don't.

The idea that these same orgs are going to pivot to NPC certification timelines because Salesforce needs to clean up its product catalog is... optimistic.

Yes, the cert stays valid after retirement. That's not the point. The point is that any org that budgeted training time and money toward the NPSP cert
just had that investment redirected by someone who was definitely not in the room when the budget conversation happened.

Anthropic launched Claude Corps.

$150M. 1,000 fellows. 12-month placements. $85,000 salary, trained by CodePath, embedded full-time into nonprofits to build AI systems and workflows.

Real program. Real money. I looked up the host org list. These are not token partnerships.

I'm just asking: what happens on month 13?

Here's what I've seen happen every single time a skilled technical resource embeds in a nonprofit and then leaves:

These aren't disasters because the original work was bad. They're disasters because there was no plan for the moment the expert walked out the door.

Claude Corps fellows are being trained on Claude. They're not being trained on nonprofit data governance, operational continuity, or what happens to a food bank's donor management system when the person who rebuilt it takes their next job.

You can't hire someone brilliant to build you a machine and then be surprised when the machine breaks after they leave. The governance plan and the handoff documentation belong in the fellowship agreement. Not month 11. Not the exit interview but on day one.

If there's already a framework for this built into the program, link it below. I'll update this post.