# Forcefields.tech > Practical notes on Salesforce consulting, project delivery, and nonprofit tech written by a practitioner. Public Ghost content for AI and LLM tooling. This file includes a bounded export of public pages first, then recent public posts. Append `.md` to any post or page URL to get the content in Markdown (for example, `/example-post.md`). ## Pages ### About this site URL: https://forcefields.tech/about/ Last updated: 2026-05-17T20:43:39.000Z I'm [Aske Bong-Saxe](https://www.linkedin.com/in/askebongsaxe/?ref=forcefields.tech) \- a Salesforce consultant with over 15 years of experience in the Salesforce space, currently Head of Functional Solutions at [Giveclarity.org](https://giveclarity.org/?ref=forcefields.tech). We are a Salesforce partner working exclusively with nonprofits. I've led implementations for organisations like Save the Children, UNICEF, and Médecins Sans Frontières. ![](https://storage.ghost.io/c/60/fe/60feeaea-39c9-4d74-a7a4-5e9fc440ecf0/content/images/2026/05/Aske-Bong-Saxe-portrait-2-1.jpg) My 'official' Giveclarity photo / photo by Andreea Tufescu I started this site because of a gap I kept noticing - not a technical one. The Salesforce ecosystem has plenty of documentation, release notes, and how-to guides. What it has less of is honest, confident writing about *how to consult well*. How to hold your ground when a client pushes back on your recommendation. How to communicate clearly when a project gets uncomfortable. How to deliver reliably, repeatedly, without drama. How to turn mistakes into earned lessons. I've been fortunate to build a strong track record in this space - large projects, complex organisations, tight timelines - and somewhere along the way I developed a fairly clear picture of what good project delivery looks like. I want to share that picture with other people. Most of what I write is aimed at Salesforce practitioners working in or with the nonprofit sector. But much of it applies more broadly to anyone in consulting who wants to develop not just their technical skills, but their nerve. If you're a junior consultant finding your feet, or a more experienced one who sometimes lets clients talk you out of the right answer - this site is for you. --- P.S. A lot of times confidence requires at least a minimum level of technical expertise. So, there will be plenty of room for technical posts, posts with a focus on governance, and other adjacent topics. Just in case I had you worried for a second. ## Posts ### Why fixed price is not the win the client thinks it is URL: https://forcefields.tech/why-fixed-price-is-not-the-win-the-client-thinks-it-is/ Last updated: 2026-08-10T08:00:39.000Z I am a consultant who works exclusively on Time&Materials projects. You might say I have a vested interest in arguing against fixed price contracts. You should weigh that accordingly when reading this. But here is the thing: I am going to make the argument anyway, because I think it holds up regardless of who is making it. "Fixed price gives us certainty." It is a message I can still sometimes hear from clients at the start of a procurement conversation. To be fair, not as much as I used to, but the sentiment is still out there. And it is completely understandable. You are about to commit significant budget to a complex project. You want to know what you are getting and what it will cost. Fixed price feels like the instrument that delivers that. A number that is agreed upfront and signed in a contract. That’s what certainty looks like. Except it is not certainty. It is the *appearance* of certainty. And those two things behave very differently once a project is underway. ### **You are paying for the risk either way** You might know this already: vendors are not absorbing your project risk under a fixed price contract - they are pricing it. Before the contract is signed, a vendor has to estimate the cost of delivering everything in scope - including all the things that might go wrong, all the requirements that might evolve, and all the complexity that is not yet visible. That uncertainty gets baked into the price as contingency. You pay for it upfront, whether or not it ever materialises. In a straightforward, well-defined project with stable requirements, that contingency might be modest. In a complex project - one with multiple stakeholders, evolving requirements, a changing system landscape, or anything where the full scope is not knowable at contract signature - that contingency can be substantial. And if the project runs smoothly, the vendor pockets the difference. You have essentially pre-purchased insurance - without knowing it - for a risk that never arrived. ### **What fixed price does to the relationship** Beyond the financial mechanics, fixed price changes something more fundamental: it changes the incentive structure between client and vendor. On a fixed price engagement, every change request is a contractual event. The client wants something adjusted. The vendor has to evaluate whether that falls within scope or outside it. If it falls outside, someone has to pay for it - and now you are negotiating, not collaborating. Change becomes adversarial by design. This has a quieter consequence that might go unnoticed. Teams stop suggesting better approaches. If a developer spots a more suitable solution halfway through the build, they face a dilemma: the better solution is different from what was scoped, and different means a conversation about money. So the suggestion does not get made. The client gets what was specified on paper, not what would have worked best. Innovation basically gets priced out of the room. ### **The complexity problem** Fixed price can work. If you are commissioning something genuinely well-defined - a specific piece of functionality with stable requirements and a short delivery window - the model has its place. The problem is when clients reach for fixed price terms precisely when projects are complex and uncertain, which is exactly when the model is least suited to the work. Complex projects have requirements that evolve as understanding deepens. Stakeholders learn things during delivery that change what they need. Systems reveal constraints that were not visible at the start. This is not a failure of planning - it is the nature of complex work. Fixed price does not make that complexity go away. It just creates a contractual structure that is poorly equipped to handle it. The choices that typically emerge seems almost predictable: - scope gets squeezed to protect the original number, or - quality quietly erodes to protect the timeline, or - the project runs over anyway and everyone argues about who owes what. None of these are good outcomes - and none of them represent the certainty the client thought they were buying. ### **What** problem**(s) are they** trying **to solve?** Most clients reach for fixed price because they are trying to solve something real. For example, budget predictability. Or protection against a vendor who runs the clock indefinitely. Maybe they've been burned in the past - who knows? Those are legitimate concerns, and they deserve legitimate answers. But it is worth being precise about which problem you are actually trying to solve, because fixed price addresses some of them less well than it appears, and others not at all. *What are we trying to protect against - runaway cost, or runaway scope?* They are related, but they are not the same problem. Fixed price puts a ceiling on cost in theory, but it does so by freezing scope - and frozen scope on a complex project is often a fiction that holds until the first significant discovery. It is a bit like planning a road trip and insisting you will not deviate from the original route - no matter what. Fine in principle, until there is a collapsed bridge halfway there. At that point, the question is not whether to change or stay the course. It is whether your plan gives you a sensible way to do it, or forces you to argue about who pays for the detour while the project sits at the side of the road. If the real concern is cost, there are ways to address that without locking scope in a way that creates problems downstream. This might include adopting an “MVP”-mindset where the simplest possible version of the product - the Minimum Viable Product - guides decision making. *Who carries the risk if requirements change - and is that the right answer?* Under fixed price, the client carries the risk of getting requirements wrong upfront, and the vendor carries the risk of estimating them poorly. If requirements do change - and on any complex project, they will - the question of who pays becomes a negotiation, not a collaboration. Is that the dynamic you want to be navigating mid-project? *Does fixed price actually give us certainty, or does it give us a number?* A signed contract with a fixed figure is not the same thing as a predictable outcome. If scope gets squeezed to protect the budget, or quality degrades to protect the timeline, you have your number - and a system that does not do quite what you needed. That is just a different kind of disappointment masquerading as certainty. *What happens to the relationship when the first change request lands?* Because it will land. The question is whether it arrives as a shared problem to solve, or as a contractual dispute to resolve. Fixed price tends to push it toward the latter. None of this means the concerns that drive clients toward fixed price are wrong. They are not. The instinct to want predictability and accountability is entirely reasonable. The question is whether fixed price is actually the instrument that delivers it - or whether it delivers the *appearance* of it, which is a different thing entirely. --- ### Should the client's business analyst write user stories for your Salesforce project? URL: https://forcefields.tech/should-the-clients-business-analyst-write-user-stories-for-your-salesforce-project/ Last updated: 2026-08-03T08:18:58.000Z *Here's a position I hold pretty firmly: user stories on a Salesforce* implementationproject *should always be written by the vendor, not the client's internal BA. Not because client BAs aren't capable, but because of what tends to go wrong when they hold the pen.* --- That's my position. Now I'll share the rationale behind it. ### **The blank canvas problem** Every generalist BA is trained to write system-agnostic user stories and acceptance criteria. From a purist BA standpoint, that's correct practice. You describe the need, not the implementation, so the solution isn't constrained before anyone's had a chance to design it properly. Before I worked with Salesforce that's exactly how I was taught to write user stories. That approach works when the underlying system is a blank canvas: an in-house CMS, a bespoke Java application, a purpose-built app built from scratch. It falls apart the moment the underlying system is a platform such as Salesforce, or any other commercial-off-the-shelf system for that matter. Salesforce and its myriad of products (Sales Cloud, Nonprofit Cloud, NPSP, Marketing Cloud etc) is flexible enough that most requirements can be met several different ways. But it also comes with a large body of native functionality that already solves problems people don't realise are already solved. When a generalist BA writes acceptance criteria without knowing what's already sitting in the platform they end up describing a system that doesn't exist yet, and doesn't need to. The result is acceptance criteria that quietly demand a custom rebuild of something Salesforce already does out of the box. Nobody intends this. It happens because the BA is writing to a methodology rather than a platform. ### **The cost of undoing it** Once those stories are written down and shared with the client's stakeholders, they stop being a draft. They become the frame of reference everyone in the room uses to judge progress, whether or not it was ever technically accurate. At that point, the consultant's job isn't just to write the correct version. It's to have the conversation where you tell the client's BA "that's not how Salesforce works", explain why the UACs as written would mean custom-building an entire suite of things the platform already provides, and then spend time and goodwill unwinding a document that's already taken root in people's heads. That's effort spent managing a misunderstanding you didn't create and had no say in preventing. ### **Whose risk is it?** There's a second problem, and it applies even if the client's BA happens to be genuinely Salesforce-fluent. If the vendor is expected to build against user stories they didn't author, the vendor has effectively lost control of the thing they're accountable for delivering. The bigger the scope covered by client-written stories, the bigger that exposure becomes. Imagine commissioning a builder for a new house, then insisting they use a cement mix *you* sourced from a recipe on the internet. If the foundation cracks, is the builder still on the hook for it? Somebody made the call on the materials, and it wasn't the person holding the liability. User stories are the materials list for a Salesforce build. If the client wrote the list, the vendor shouldn't have to explain the cracks. And thirdly, most Salesforce consultancies have their own custom-built solutions to address common use cases (they might call them accelerators or similar). The client BA would of course not know about them and therefore naturally wouldn’t have them in mind when drafting user stories. ### **Where client BAs still matter** If you're a client BA, please don't worry though, there's still plenty for you to do. Client BAs are often the best people in the room to deliver process diagrams, for clarifying business rules, and for capturing how the organisation actually operates day to day. That knowledge is valuable and a Salesforce consultant would be foolish to ignore it. They're also essential at the other end of the process: reviewing and signing off on the stories the vendor produces. That sign-off isn't a formality. A vendor should never be building against user stories the client hasn't reviewed and approved, regardless of who drafted them. The distinction that matters isn't whether the client's BA is involved, it's who holds the pen during drafting and who holds the approval before build starts. ### **The one exception** There's one stage where client-drafted stories can be genuinely useful: presales. Before any commitment has been made on the vendor's side, seeing a client's own attempt at user stories can tell you a lot about their priorities and give you an early read on their internal terminology. At [Giveclarity](https://giveclarity.org/?ref=forcefields.tech) we've had a handful of presales engagements where a client's BA wanted to draft, or help draft, the project's user stories. It's an understandable instinct. It looks like a natural place to put the responsibility, and it saves them budget. We tried it once. We don't do it anymore. Once a project moves past presales into Discovery and Build, client-authored stories stop being a useful data point and start being a risk sitting inside the delivery. ### **Where this leaves you** In my experience, the BA relationship on a platform project only works one way round: - The vendor writes the stories, because the vendor is the one who understands what the platform already does and what it will cost to fight it. - The BA reviews and signs off on every one of them, because that's what keeps the vendor accountable for what gets built. Client BAs still have real work to do on process, rules and terminology, and their sign-off is not optional. But the pen stays with the people who carry the risk of what happens if the story is wrong. --- ### How to (not) annoy your tester URL: https://forcefields.tech/how-to-not-annoy-your-tester/ Last updated: 2026-07-27T08:00:36.000Z *I spent the early days of my IT-career as a part-time tester and found* myself *on the* receiving *end of what I call the "fixed it"-attitude. Here's what that* attitude *costs, and why I made sure never to inflict it on my own tester colleagues.* --- Picture the scene. A tester logs a bug. A day later, the ticket gets a single line reply from the developer: "Fixed it". No detail on what was wrong, no explanation of why it happened, and no note on what was actually changed. On paper, the bug is closed of course. But in practice, something more corrosive happens: the tester has learned they can't trust a status update at face value. ### **The one-line reply** becomes **a trust problem** It's tempting to read "fixed it" as a minor lapse in communication habits. I don't think that's what it is. It's an indication, intentional or not, that the developer sees testing as a formality to clear rather than a working relationship to maintain. Left with nothing but that vague statement, the tester is stuck guessing at three separate questions: - Did the developer understand why the bug happened, or did they just patch the symptom? - Was the fix actually unit tested, or just assumed to work? - Is this the kind of issue that's going to quietly resurface in three weeks’ time under a different name? None of those questions get answered by the "fixed it" statement. And because the tester can't answer them, they have exactly one rational response: stop trusting the developer and start verifying everything from scratch, every time. Which is, ironically, slower for everyone than a short explanation would have been. ### **What good looks like** The solution to this isn't complicated. But it requires treating the tester as an important part of the development process rather than an obstacle between you and a completed user story. **Be transparent about the root cause, even when it's embarrassing.** If the bug was caused by a missed edge case, an outdated assumption, or, yes, a genuinely careless mistake, say so. "I hadn't accounted for records with no associated contact" tells the tester something useful. "Fixed it" tells them nothing, and it invites them to wonder what you're *not* saying. ### **Write for your future self, not just the tester in front of you** A decent bug note is a message in a bottle to whoever picks up this area of the application eight months later, and there's a reasonable chance that person is you, minus the context you currently have in your head. A short paragraph on cause, impact, and solution costs you 2-3 minutes *now*. Reconstructing that same understanding from scratch later, mid-incident, costs considerably more than that. **Leave the ego at the door.** Testing isn't an adversarial exam you pass or fail. It's quality control that exists because nobody, however good, ships perfect code on the first attempt *every* time (but boy does it feel great when it happens!). Treating a bug ticket as a personal critique, and responding to it defensively or dismissively, tells the tester that raising issues comes with a cost. That's the wrong incentive to create in a team that depends on people speaking up candidly. ### **A template, more or less** None of this needs to be an essay. A workable structure looks something like: - **What was wrong:** a plain description of the actual defect, purely observational. - **Why it happened:** the root cause, in a sentence or two (prepare for the occasional embarrassment here). - **What changed:** the fix, described concretely enough that someone could sanity-check it without re-reading the code or config. - **What this means going forward:** anything the tester or a future reader should know, such as related areas worth a second look. That's it. I have tried - and continue to try - to incorporate this practice into my own work when passing bug tickets back to testers. I’ll leave it to them to judge whether I’ve been successful in that endeavour. **Why this matters more than it seems to** There's a version of this argument that says, clear bug notes are just good practice, full stop, the kind of thing every engineering handbook already tells you to do. Fair enough. But I think the more interesting point is what happens to a team's dynamics when this habit is absent for long enough. When testers can't trust a "fixed" bug ticket, they start double-checking everything, which slows down the whole test cycle. When developers feel every bug is scrutinised as a personal failing, they get defensive, and defensive people are worse at admitting when something's actually broken. Put those two things together over a few sprints and you get a team where testing feels adversarial rather than collaborative, and where the actual quality of the product quietly suffers because neither side is being fully honest with the other. None of that gets solved by a policy or a Jira template, although a template helps. It gets solved by developers deciding, ticket by ticket, that a tester finding a bug is not an accusation. It's someone doing their job, and doing yours a favour in the process. So, next time you're tempted to just write "fixed it" and move on, consider spending the extra minutes. Your tester will trust the next ten tickets a lot more than they would have trusted this one on its own. And "future-you" will break into a warm smile when you see how conscientious "past-you" was. --- ### Salesforce's permissions U-turn was the wrong call URL: https://forcefields.tech/salesforces-permissions-u-turn-was-the-wrong-call/ Last updated: 2026-07-20T08:00:18.000Z *Salesforce didn't just delay the retirement of profile-based permissions. They cancelled it! Here's why their response doesn't match the complaint, and why the case for migrating to permission sets hasn't actually changed.* --- Salesforce recently [cancelled its plan](https://www.salesforceben.com/salesforce-backtracks-on-permission-retirement-in-profiles/?ref=forcefields.tech) to retire system permissions from profiles. The move had been on the roadmap since 2023, was due to begin rollout in the Spring '26 release, and is now shelved with no new date attached. Salesforce cited customer feedback and feature gaps as their reasons. The Salesforce community's reaction, based on the coverage I've seen, has been a mix of relief and "not totally surprised". Fair enough, Salesforce has a track record of moving controversial deadlines. But I want to make a different point: they didn't just delay this change. It was a full cancellation of the direction of travel, and other than "we're really into Agentforce right now", I can't see a good reason to go that far. ## The complaint was real - the response wasn't proportionate I understand where the pushback came from. Profiles are deeply embedded in orgs that have been running for years. Migrating to a permission set-centric model on a fixed deadline means months of analysis, testing, and change management, for a change that produces no visible business impact for the organisation. In a lot of enterprise contexts, that's a hard sell against anything revenue-generating. That's a legitimate case for phasing the deadline, or extending it, or scoping it by org complexity. It is not a case for cancelling the initiative altogether. Salesforce had a whole menu of options that would have respected the complaint without also telling every customer "the pressure to fix this is gone“. Instead they picked the one option that removes the incentive to fix anything. Some of those options could look like this: - **Freeze forward, don't touch the past.** From a set date, no new system or object permissions can be added to any profile, existing or new. Existing profiles keep what they have. Every incremental grant from that point on goes through a permission set. This stops the bloat problem at the source without breaking anything already in place. - **New orgs go permission set-only.** Existing orgs keep their profiles for now, but any org created after a given date cannot assign system permissions via profiles at all. - **No new profiles, full stop.** Existing orgs keep their existing profiles indefinitely, but from a set date they can no longer create new ones. Any new access requirement has to be built as a permission set. - **Tiered runway by complexity.** A small org with ten profiles doesn't need the same multi-year grace period as an enterprise org with two hundred profiles. Give the simple orgs a short deadline and the genuinely complex ones the longer runway. A blanket cancellation rewards whoever dragged their feet longest and does nothing for whoever already started the work in good faith. - **A sunset clause, not an open-ended cancellation.** Keep profiles alive, but attach a hard, published end-of-life date, five years out, ten years out, whatever's realistic. There's a real difference between "delayed, with a firm date attached" and "cancelled, no date, don't ask." Salesforce picked the version that removes all pressure. - **Flag it without breaking it.** Surface profile permission bloat as an escalated severity item in the Security Health Check menu, visible to admins and auditors, without a hard technical cutoff. It keeps the pressure social and reputational instead of a cliff edge, which might have been a reasonable middle ground if the real worry was breakage rather than effort. Any of these would have kept the direction of travel intact while giving enterprise customers the breathing room they were asking for. Salesforce didn't need to choose between 'hard deadline' or 'no deadline at all'. They chose the second one anyway. ## Profiles bloat because they're one-dimensional Here's the part that actually bothers me, beyond the process question. I've reviewed a fair number of orgs over the years, and profile-based permission models tend to converge on the same failure mode: they get overly permissive, not because anyone made a bad decision, but because of how profiles are structured. Take a fundraising team. Brian works Major Donor and Sarah works Corporate Fundraising. Both sit on the same "Fundraising User" profile because, at the time it was built, their access needs looked similar enough to share. Later, Sarah picks up some Community Fundraising responsibilities and needs access to a new set of fields and objects. Someone updates the shared profile to give her that access. Brian now has it too. Not because he needs it. Because he happens to share a profile with someone who does. Multiply that over a few years and a handful of role changes, and you get a profile that grants far more than any individual on it actually uses. Nobody made *one* wrong decision. The structure just doesn't support granularity, so every incremental change leaks sideways into everyone else on the same profile. Permission sets handles it cleanly. Sarah gets a "Community Fundraising Access" permission set group assigned to her, and *only* her. Brian's access stays exactly where it was. Nobody's default footprint expands just because a colleague's job description did. That's what principle of least privilege looks like in practice: access that maps to the person and the task, not to whichever bucket they were sorted into years ago. The forced migration deadline was, whether Salesforce framed it this way or not, a genuinely useful nudge to revisit the bloated profiles. It gave admins and consultants a mandate to say "we have to do this anyway, so let's do it properly". That mandate is gone now. The incentive hasn't been removed for the customers who were already disciplined about this. But it's been removed for everyone else, which is probably most orgs I imagine. ## Where this leaves security posture Salesforce has [spent the last year](https://help.salesforce.com/s/articleView?id=005228017&language=en%5FUS&type=1&ref=forcefields.tech) talking about security and risk in [increasingly serious terms](https://www.salesforceben.com/june-2026-security-requirements-what-to-expect-and-how-to-prepare/?ref=forcefields.tech). That's great! But you don't get to talk about a more purposeful security posture in one breath and, in the next, cancel one of the more meaningful structural nudges toward exactly that posture. The two positions don't sit well together. We all know it isn’t a single security setting that will make or break your org. An org’s security posture is made up of layers upon layers of security settings and practices. The permissions which are granted through a user’s profile is a significant factor in those layers. The Salesforce data breaches in [2025](https://www.salesforceben.com/salesforce-data-theft-roundup-everything-you-need-to-know/?ref=forcefields.tech) and [2026](https://www.salesforceben.com/shinyhunters-breach-400-companies-via-salesforce-experience-cloud/?ref=forcefields.tech) have likely been exacerbated by overly permissive user settings. Here's my take: treat the cancellation as Salesforce's problem, not yours. The best practice hasn't changed just because the enforcement mechanism disappeared. If you're an admin or a consultant sitting with a client's bloated profile model, the case for migrating to permission sets is exactly as strong today as it was the week before this announcement. You just no longer have Salesforce's deadline to point to when you make that case internally. You'll have to make it on the merits instead. Which, frankly, you should have been able to do anyway. Salesforce is betting that most orgs will take the path of least resistance now that nobody's forcing the issue. My hope is that we'll do better than Salesforce is apparently expecting of us. --- ### Why "is this really a bug?" is a harder question than it sounds URL: https://forcefields.tech/why-is-this-really-a-bug-is-a-harder-question-than-it-sounds/ Last updated: 2026-07-13T09:02:53.000Z *Do you ever evaluate and re-categorise tickets raised by your client? It may create a bit of friction to challenge the client's assertions. But avoiding it will cost you in other ways.* --- A client raises a ticket. They categorise it as a bug. Nine times out of ten, nobody on the delivery team stops to check whether that's actually true. It sounds like a pedantic thing to challenge. In my view, it isn't. The label on a ticket does two jobs at once. At the micro level, it tells the team what kind of work is required and how urgently. At the macro level, hundreds of these labels get rolled up into a narrative about the health of the project. Get the labelling wrong often enough, and you end up with a steering committee genuinely believing the project is riddled with defects, when what actually happened is that requirements evolved and nobody bothered to say so. ### **The three categories, and why they get confused** - A **bug** means the system is not doing what was agreed it would do. There was a specification, implicit or explicit, and the build does not match it. Something is broken relative to an existing standard. - An **improvement** means the system is doing exactly what was agreed, but someone has since realised a more suitable way to do it. Nothing is broken. The bar has simply moved, usually because the team (rightly) learned something mid-project that it didn't know at the start. They’re also usually complementary to existing features rather than being new features in their own right. - A (new) **user story** means nobody previously agreed to this at all. It's new scope, dressed up as a follow-on task because raising it as "new scope" feels like it will trigger a bigger, more awkward conversation about budget and timeline. Depending on its complexity it may initially be considered a **Change Request**. The confusion is rarely malicious. It's a matter of incentives, but not the incentive you might assume. On a Time & Materials engagement, the client is paying for the time either way, whether the ticket is a bug, an improvement, or new scope. In other words, calling it a "bug" doesn't make the work free. What "bug" does is put the onus on the vendor. It reframes the ticket as something the vendor got wrong, which signals urgency and priority, and implicitly puts the vendor on the back foot to fix it fast, ahead of the queue, without much debate about sequencing. "Improvement" and "user story" don't carry that weight. They sit in a backlog, get prioritised against other work, and can be argued over. Calling something a bug is, whether consciously or not, a way of skipping that queue. So, there's a quiet, mostly unconscious pull toward labelling everything a bug, not to get something for free, but to get it fixed *now*. ### **Why this matters more than it *looks* like it should** Ticket categorisation is not just an admin exercise. It's the raw material for the story that gets told about the project. Someone, at some point, is going to pull a report that says "47 bugs logged last sprint" and hand it to a steering committee. Nobody in that meeting is going to open each ticket and re-litigate whether it was really a bug, a reasonable scope refinement, or a new idea someone had in a workshop. They're going to take the number at face value, and the number is going to shape how the whole engagement is perceived, regardless of whether it's an accurate reflection of what actually happened. This is how a project, that is perhaps broadly on track, ends up being discussed in terms of "quality concerns". Not because the delivery was poor, but because a category error at the ticket level quietly snowballed into a narrative at the steering committee level. And once that narrative takes hold, it's remarkably hard to undo with facts. Perception, once formed, does most of the subsequent thinking for people. It's even more difficult if the narrative has become "the timeline and budget has been exceeded, and it's due to all the bugs". If that is indeed the root cause of a project delay, then so be it - get it sorted. But if it genuinely is *not*, then it's in your interest to prevent that narrative from forming. If the root cause of the project delay is due to endless iterations on requirements and changing of opinions - rather than bugs - then that's worth calling out and backing up with evidence. ### **Whose job is it to get this right** Here's the simple answer: it's the consultant’s, not the client's. Clients, understandably, are not thinking about the downstream reporting implications when they raise a ticket. They're thinking about the immediate annoyance in front of them, and "bug" is the label that requires the least justification. Expecting client-side team members to consistently and correctly self-categorise their own tickets is expecting a level of discipline that has nothing to do with their job and everything to do with yours. That means someone on the delivery side needs to be the checkpoint. Not adversarially, and not as an accusation that the client is trying to jump the queue. Most of the time they aren't; they genuinely don't know the difference, or haven't thought (long) enough about it. The fix is simple: before a ticket goes into the sprint, ask two questions: - What was actually agreed before the feature was built, and does the current behaviour deviate from it? If “**yes**”, it's a bug. Usually, this would mean material deviance from the user acceptance criteria on a user story ticket. - If nothing was agreed, or the ask post-dates the original design, is this a refinement of existing scope (improvement), or something genuinely new (user story)? If the answer to the first question is “**no**“, say so. Not defensively, not as a "gotcha", just as a plain reclassification with a one-line rationale attached to the ticket so the client can see it too. This is a small piece of friction that pays for itself many times over, because it protects the integrity of every report that gets built on top of these tickets later. ### **The habit worth building** None of this requires new tooling or a new process document nobody will read. It requires a habit: read every incoming ticket with a moment of scepticism before accepting its label. Ask what was actually promised, not what the client assumes was promised. Re-categorise where needed, and do it consistently. It's a small discipline. But it's the difference between a steering committee discussing your delivery quality, and a steering committee discussing what was actually delivered. --- ### Getting permissions right the first time URL: https://forcefields.tech/getting-permissions-right-the-first-time/ Last updated: 2026-07-06T12:13:38.000Z *This one is for the practitioners - admins and consultants who have lived through a go-live where permissions were an afterthought. You'll recognise the pattern.* --- There is a shortcut that appears on certain Salesforce implementations, usually around the point where testing begins and someone needs to be unblocked. It sounds reasonable in the moment and is offered with good intentions. But it quietly stores up one of the most avoidable sources of pain in the entire project lifecycle. The shortcut is this: grant testers System Administrator access so they can move faster. The person who suggests it - sometimes a project manager on either side of the table, vendor or client - genuinely believes they are helping. They see a blocker. They have a lever, so they pull it. If the consultant is overly accommodating they might even agree to it, because it eases the friction. But they do so without foresight of the impact it will have later. ### Why it backfires When testers operate with System Administrator rights, they can do things that end users will not be able to do in the live system. The system appears to work and defects go undetected. Permission-related bugs stay hidden because the tester's elevated access quietly leaps over them. Everything looks fine - until go-live, when real users with real permission setups encounter a system that was never actually tested for them. At that point, features that "passed" testing begin to fail. The team scrambles to diagnose issues that shouldn't exist. Developers troubleshoot problems caused not by the solution, but by the test environment it was tested in. It is expensive, demoralising, and entirely avoidable. There is also a second problem, which is less technical and more human. Once elevated access has been granted, rolling it back becomes difficult. End users who have been given System Administrator rights tend to hold onto them. There is an element of status involved - elevated system access confers a certain sense of importance - and there is a genuine fear that removing it will cause disruption. What was intended as a temporary shortcut quietly becomes a permanent fixture. Which brings us to a point worth calling out. ### A pattern that deserves its own mention The testing scenario is one instance of a much older and more persistent problem: live Salesforce orgs where large swaths of users - sometimes every user - has System Administrator rights in Production. This is not a theoretical risk. It is extremely common. It happens partly through accumulated shortcuts like the one described above, and partly because self-taught administrators, understandably, find it easier to grant broad access than to diagnose and resolve specific permission gaps. The result is an org where the security model exists on paper and nowhere else, where there is no meaningful separation of responsibilities, and where a well-meaning user with no malicious intent can cause serious damage simply by having access they were never supposed to have. If this describes your org, you already know it. The question is whether you have a plan to address it. ### The right approach: design permissions upfront, deliberately The alternative to the shortcut is not complicated, but it does require discipline and a willingness to hold the line when pressure builds. Permissions should be designed before development begins and enforced throughout testing. That design should be grounded in a small number of clear principles. The most important one, in practical terms, is this: a permission should be governed in one place. If the same object or field-level security permission can be granted through two or more different permission sets or profiles, it becomes ambiguous - both during implementation and later during operations. The developer doesn't know where to add access. The administrator doesn't know where to look when something breaks, or which version of the permission to assign to the user. Ambiguity in a permission model is a debt that compounds over time. On the question of profiles versus permission sets: profiles are one-dimensional. A user has just one profile, which means every permission decision made at the profile level is a blunt instrument applied uniformly. Permission sets and permission set groups allow you to be granular - to grant specific access to specific roles without contaminating the broader security model. They make it genuinely feasible to deliver on the [Principle of Least Privilege](https://en.wikipedia.org/wiki/Principle%5Fof%5Fleast%5Fprivilege?ref=forcefields.tech), which is the goal. Profiles still exist and still have a role, but governing system permissions through them in 2026 is working against the tool rather than with it. CRUD (Create, Read, Update, Delete) and field-level security (FLS) should also be treated as separate concerns. Logically, they are related - you cannot have meaningful FLS access without some degree of CRUD access to the underlying object. But they should never be conflated in the permission design. A user may legitimately need object-level access without needing access to every field on that object. Building that separation in from the start is far easier than retrofitting it later. ### What "upfront" actually means Designing permissions upfront does not mean producing a theoretical document that nobody consults during the build. It means defining the permission model as a concrete, enforceable design decision - which profiles exist, which permission sets govern which access, how CRUD and FLS are separated, and who holds the authority to grant exceptions. That model then becomes the reference point against which testing is conducted. Testers should test as end users, using the permissions that end users will have at go-live. Issues that surface during testing - and they will - are a feature, not a failure. They are exactly the kind of thing you want to discover in a sandbox rather than in Production. When a well-meaning project member suggests giving testers admin access to unblock a sprint, the correct response is not to comply and move on. It is to explain, clearly and without drama, what that shortcut will cost downstream - and to offer the alternative, which is to diagnose and resolve the actual permission issue. That takes longer in the short term. It costs considerably less in the long term. Permissions are rarely the most exciting part of a Salesforce implementation. They sit somewhere between "foundational" and "invisible" - nobody notices them when they work, and everybody notices them when they don't. Perhaps that is exactly why they keep getting deferred. The costs are invisible until they aren't. --- ### Nobody wins when a Change Request becomes a blame game URL: https://forcefields.tech/nobody-wins-when-a-change-request-becomes-a-blame-game/ Last updated: 2026-06-29T08:31:32.000Z *Most change request conversations don't go wrong because of the change itself. They go wrong because someone in the room starts looking for who's to blame.* --- There is a version of a change request conversation that goes badly almost every time. Someone on the client side looks across the table and says, with barely concealed irritation: "How did we not know about this earlier?" Someone on the consultant side responds defensively, over-explains, and possibly apologises. The CR gets signed, eventually, but the atmosphere has shifted. A considerable amount of trust has quietly left the room. It does not have to go that way. And in my experience, when it does, the damage is rarely caused by the change request itself. It is caused by how both sides respond to it. ### The majority of CRs are not caused by mistakes Let me say something plainly: in my years of delivering Salesforce projects, I cannot point to a single meaningful implementation that did not produce at least one major change request (and a bunch of smaller ones). Not one project. And the majority of CRs were not caused by anyone forgetting something, or missing something obvious, or failing to ask the right question. They happened because complex projects generate new knowledge as they progress - and new knowledge, almost by definition, changes things. This is not a consultant (me) making excuses. It is simply how any complex work operates. It just becomes more obvious to everyone when billable money is involved. The first month of a project, you are working with what everyone collectively knows at that point. Six months in, you know considerably more - about the client's data, their processes, their edge cases, their internal politics, the gap between how they *think* things work and how things *actually* work. Some of that knowledge will change the shape of the solution. I don’t think of that as a planning failure. That is the project doing what it is supposed to do. The more honest framing of a change request is this: a CR is a document that says "we have learned something, and here is the impact of that new knowledge". That framing sounds almost too simple, but it matters. Because it is the opposite of the framing that causes damage, which is "someone made a mistake and now someone is paying for it." ### When a genuine mistake is involved There is a version of CRs that does involve a genuine mistake. A consultant misinterprets a requirement. An assumption slips into the build without being explicitly validated. Something that should have been caught during the Discovery phase was not. These things happen, and when they do, the right response is different: acknowledge it dispassionately, describe the impact, outline the fix, and move on. No drama. No self-flagellation. No lengthy apology that implies fault where fault actually exists, which only invites the client to agree with you. But this version is, in my experience, the minority. Most CRs are not about mistakes. They are about the natural rhythm of learning on a complex project. The problem is that clients - entirely reasonably - sometimes cannot tell the difference. A change request looks the same whether it was caused by a genuine oversight or by a legitimate evolution in understanding. And if the consultant responds to every CR with an apology, they are implicitly training the client to treat all of them as failures. That is a bad habit, and it compounds over time. ### The real problem is the blame dynamic Here is what actually causes damage in a CR conversation: the search for blame. When a change request becomes an exercise in establishing whose fault it is, two things happen. Firstly, it wastes time that should be spent solving the problem. Secondly, it introduces a dynamic that will follow the project for months. Both sides start hedging. The consultant becomes risk-averse, spending billable time covering ground that has already been covered rather than moving forward. The client becomes suspicious of future recommendations. What was a collaborative working relationship starts to feel adversarial. The cost of that dynamic is rarely visible on a spreadsheet, but it is very real. Projects slow down. Good ideas stop being surfaced because the political cost of raising them feels too high. The whole thing becomes harder than it needs to be. The antidote is simple, even if it is not always easy. Treat the change request as a shared problem, not an accusation. Describe what changed and why. Frame it in terms of what the project now needs rather than what (or who) was wrong. And as a consultant I urge you to resist the instinct to apologise reflexively. Because reflexive apologies, however well-intentioned, invite exactly the blame dynamic you are trying to avoid. ### A note for the client side If you are on the client side reading this: a change request from your implementation partner is almost certainly not a signal that you hired the wrong people. It is almost certainly a signal that your project is progressing. The right question to ask is not "why did this happen?" but "what do we need to do now?" - and then, separately, whether the governance and process around change control is working well enough to manage these things calmly when they arise. Because they will arise. On every project worth doing, they will arise. That is not a problem. That is just how this works. --- ### Don't avoid the hard conversation. Do prepare for it. URL: https://forcefields.tech/dont-avoid-the-hard-conversation-do-prepare-for-it/ Last updated: 2026-06-22T08:00:04.000Z There is a particular kind of consultant behaviour which treats difficult stakeholder conversations as something to be avoided, postponed, or softened into meaninglessness. That behaviour makes us send vague emails that say "something to keep an eye on", or "thought you should know this". And it waits for the problem to become undeniable before they say anything useful. While a *potentially* difficult conversation is brewing it’s not always obvious if the circumstances warrant being elevated to “we need to address this”. They say to pick your battles, right? And you also don’t want to be perceived as being alarmist. I think that tension - along with a fear of perhaps disappointing the people around you - is what sometimes makes us bide our time. However, difficult conversations, handled well, do not have to drain momentum from a project. Instead, they can actually *create* the momentum. The catch is that "handled well" takes some preparation - and some people skip that part. ### Why preparation is the whole game When you walk into a difficult conversation without grounded evidence, you are essentially asking a stakeholder to take your word for it. If the stakes are high, this rarely goes well. The moment they push back, you are left defending an opinion rather than a position. The conversation either collapses or could turn adversarial. What changes the dynamic is arriving with a credible, specific prediction of what happens if your advice is ignored. Not a vague warning. Not "this could cause an issue." A plausible failure path with a real cost attached - endless support backlogs, broken reporting, slower deployments, a system that fails at the worst possible moment. Before a difficult conversation, I sometimes choose to send a short note and relevant artifacts in advance. Data points, risk scenarios, test results - whatever is relevant. The purpose is to avoid overwhelming the stakeholder(s). It is to make sure they have context before they are sitting across from you and have to process new information under social pressure. That is not a fair position to put anyone in, and it does not tend to produce good decisions. ### A three-step plan that actually works Once you are in the room, I find a consistent structure helps. **Start with a clear preamble.** State what you want to talk about and why it matters: "I want to talk about X today, and the outcome will affect Y." It doesn't have to be presented with the "[Imperial March](https://www.youtube.com/watch?v=-bzWSJG93P8&ref=forcefields.tech)" as the metaphoric soundtrack. It can be presented respectfully and without drama. It signals that you have something specific to raise, that you have thought it through, and that you are not ambushing anyone. **Frame the trade-off.** Describe the plausible failure path and its consequences: "Here is what I do not want to see happen." Keep it calm and specific. You are not threatening the stakeholder. You are just showing them what you are trying to help them avoid. The difference matters - one sounds like a warning, the other like a partnership. **Close with a choice.** This is the part some consultants fumble. After making your case, the temptation is to either capitulate ("but of course it's your call") or keep pushing until the stakeholder agrees. Neither is right. The correct move is to hand the decision back, cleanly: "I have given my point of view. I need you to make the final decision." Then document it. Who decided, what was decided, and the context behind it. That last step - documentation - is less about covering yourself than it is about clarity. Purely verbal decisions tend to develop amnesia over time. Especially if hindsight reveals it was the wrong decision. ### Tone is doing more work than you think The script is almost beside the point if the tone is wrong. Calm and specific. Brief. No drama. Consultants sometimes confuse passion for persuasion. They become animated, repeat themselves, push harder when they sense resistance (I've done that myself sometimes). It rarely helps and often backfires. If you want to be taken seriously in a difficult conversation, the most effective thing you can do is sound like someone who has thought about this carefully and is not particularly rattled by disagreement. Which - if you have actually done the preparation - you should not be. ### What this builds over time The short-term goal of a difficult conversation is a clear decision. The long-term effect is something more valuable: credibility. Stakeholders learn patterns. When you consistently surface risks early - not after the fact, not buried in a status update, not wrapped in so many qualifications that the point is lost - they start to trust your read on things. They know that when you say something is a problem, it probably is. That trust is hard to build and easy to lose. Winning the conversation is not the objective. A stakeholder who feels outmanoeuvred in a difficult conversation is not an ally. The aim is a clear decision, made with full information, owned by the right person. Everything else follows from that. If that still feels uncomfortable, here is an alternative framing: the conversation you are avoiding is never as difficult as the one you will have to have three months later when the problem has materialised and everyone wants to know why nobody flagged it. --- ### Enable security settings before you build anything. No, really. URL: https://forcefields.tech/enable-security-settings-before-you-build-anything-no-really/ Last updated: 2026-06-15T08:00:31.000Z *Most Salesforce projects don't fail because of a technical misconfiguration. But* sometimes *they fail because someone made a series of reasonable-sounding decisions in the wrong order. This is about what happens when that wrong order puts the system’s security at risk*. --- There is a step in every greenfield Salesforce implementation that is both important, easy to perform, and routinely skipped. Before any development begins - before you create a single sandbox, before you configure a single object, before you run your first Flow - you should enable all relevant [security settings](https://security.salesforce.com/security-best-practices?ref=forcefields.tech) and [Release Updates](https://help.salesforce.com/s/articleView?id=xcloud.release%5Fupdates.htm&type=5&ref=forcefields.tech) in Production. Not as a task on the backlog. Not as a "we'll get to that" item. As a prerequisite to everything else. I don’t think this is a controversial position. Most experienced Salesforce implementers would nod along if you put it to them. And yet, in practice, it gets overlooked with surprising regularity. ### **Why it matters more than it sounds** Salesforce sandboxes are created as copies of Production. That means whatever security posture exists in your Production org at the point of sandbox creation is what gets inherited downstream. If those settings are not yet enabled, every sandbox you spin up will be working from the wrong baseline - and everything you build in them will be built against it. The consequences tend to be invisible for a while. Development proceeds, the functional testing passes, and everything seems fine. Then, at some point, someone suggests enabling those security settings, and the atmosphere in the room changes. Because by that point, the plumbing is already in. The floors have been laid. Nobody wants to think about what "enabling the security settings now" actually means in practice. What it means, in practice, is regression. Features that passed testing under a more permissive configuration may behave differently under the correct one. Automations, permission logic, integration behaviour - any of these can be affected. The team now faces a choice between proper remediation, or hoping for the best. ### **The specific failure I have seen** Years ago, I was brought in as a contributing consultant on a project that was deep into its delivery phase. During UAT, it became clear that the relevant security settings had never been enabled in Production - which meant they had never been active in any of the sandboxes, and everything had been built and tested against the wrong security baseline. The right course of action would have been to enable those settings, retest, fix whatever (might've) broke, and go live with confidence. Instead, the lead consultant - understandably anxious about the short-term disruption - made the call to proceed as-is. The project went live with security settings that should have been active from day one sitting quietly disabled in the background. Nobody celebrated that decision. It was a pragmatic response to a problem that should never have existed. ### **Why teams fall into this trap** I don’t think it’s laziness. I believe it is sequencing logic that feels reasonable, but is not. The thinking usually goes: we will set up the environments first, get building, and handle the security configuration once we know what we are dealing with. It sounds like a sensible division of concerns. The problem is that security settings are not an overlay you can just apply to a finished system. They are part of the foundation. Enabling them late is the Salesforce equivalent of building a house and then trying to install the plumbing and wiring after the walls are up. Technically possible, but significantly more painful than it needed to be. And also entirely avoidable. ### **What good looks like** Before any sandbox is created: - Enable the relevant security settings in Production - Activate the applicable Release Updates, also in Production - Confirm the [Health Check](https://www.salesforceben.com/salesforce-health-check/?ref=forcefields.tech) baseline is where it should be. Where? In Production of course! This takes a fraction of the time that retrofitting it later will cost. It means that when issues surface during sandbox development - and some will - they surface early, in low-stakes contexts, as a routine part of the build process rather than as a late-breaking emergency. In the same spirit, give early thought to your object-level Organisation-Wide Defaults (OWDs). OWDs govern how records are shared across your org, and they sit at the base of your entire sharing and security model. Unlike the security settings above, it is not always practical to lock OWDs down before a single sandbox is created - the data model may not be sufficiently defined at that point. But they should be on your radar from the first week of development, not the last. Changing OWDs late in a project is not impossible, but it can trigger a cascade of sharing rule recalculations and unexpected access behaviour that is time-consuming to unpick and hard to explain to a client who thought testing was finished. Issues found during unit testing are cheap. Issues found during UAT are expensive. Issues that make it to go-live are something else entirely. ### **The practical ask** If you run implementations, treat this as a prerequisite rather than a task. It should appear on your project initiation checklist alongside environment setup, not after it. It should be done *before* the first sandbox refresh or setup. If you are joining a project mid-stream and this has not been done, raise it immediately. Do not wait for UAT to surface it. The earlier the conversation happens, the more options everyone has. Security configuration is not the most glamorous part of a Salesforce implementation. But it is one of the few areas where getting the sequence wrong has consequences that compound quietly and surface loudly - usually at the worst possible moment. Do it *first*, and do it in Production. Then build everything else on top of it - that’s what good security posture looks like. --- ### The skills that matter most has no Trailhead badge URL: https://forcefields.tech/the-skill-that-matters-most-has-no-trailhead-badge/ Last updated: 2026-06-08T11:09:29.000Z *Everyone in the Salesforce ecosystem is scrambling to stay current with AI. Fewer people are asking whether they're investing in the skills that actually matter most - and that AI is worst at.* --- I attended [London's Calling](https://www.londonscalling.net/?ref=forcefields.tech) this year for the very first time. It was a great experience overall and I definitely hope to be back next year. My last session of the day was delivered by [Pei Mun Lim](https://www.linkedin.com/in/pmlim/?ref=forcefields.tech) and was titled "Architecting and Future-proofing your career in the age of Agentforce and AI." Given the title, I walked in expecting something semi-technical. A map of the Agentforce ecosystem, perhaps. A guide to which certifications to chase next? That's not what I got. And I left in a better mood than when I arrived. Pei's session wasn't about tools or platforms at all. It was about what makes *humans* genuinely valuable in a workplace that is increasingly shaped by AI. Things like good judgement and emotional intelligence. The ability to read a room, hold a difficult conversation, or know when the right answer is to do less, not more (sounds [familiar](https://forcefields.tech/if-your-client-makes-all-the-decisions-what-do-they-need-you-for/)!). I'll admit my first instinct was mild surprise. But sitting with it on the train home, I came to believe the mismatch between the title and the content was part of the point. ### **"Future-proofing" has been hijacked** That phrase is everywhere right now. On LinkedIn, in job specs, in conference agendas. And in almost every case, it means some version of the same thing: learn the new tools, get the new certifications, stay current with the platform. That's not bad advice. Keeping pace with what Salesforce is building matters in our field, and Agentforce represents a genuine shift in how the platform works. But if that's your *entire* strategy for staying relevant, I think it's time to hit pause. Here's the uncomfortable logic: if AI is best at the tasks that are routine and repeatable, then doubling down on those same tasks is not a long-term play. The consultants most anxious about being replaced might also be the ones investing least in the skills that are hardest to automate. Knowing how to configure an AI agent is useful, yes. Knowing when not to deploy one, and being able to make that case to a client who has been told by a sales executive that Agentforce will solve their problems, is worth considerably more in my view. Future-proofing, properly understood, might mean becoming less like the thing that could be replacing you. That means getting more comfortable with ambiguity, context, and situations where there isn't a clean answer in the documentation. ### **Judgement doesn't have a Trailhead badge** This is what I think we need to remind ourselves sometimes. Good judgement is hard to demonstrate, hard to hire for, and almost impossible to fake consistently over time. It doesn't show up on a CV in any meaningful way. There's no certification for it. And yet, in my experience, it's the single biggest differentiator between a consultant who delivers real value and one who simply delivers output. What does judgement actually look like in a Salesforce consulting context? It's the moment in a workshop when you can feel a requirement heading in the wrong direction, and you say something rather than writing it down and building it later. It's recognising that a client's stated need and their actual need are two different things, and having the confidence to name that gap. It's knowing when a solution has become more complex than it needs to be, and being willing to push back on it even when the directive is coming from someone with clout. It's also knowing when to stay quiet. When to let a stakeholder reach a conclusion themselves rather than pushing them towards it. When the meeting needs to slow down, not speed up. None of this is teachable in the way that Flow configuration is teachable. It develops through experience, through paying attention, and through the occasional uncomfortable conversation that you learn from afterwards. It's also, frankly, the part of the job that most people find hardest, because it requires a level of confidence that can feel uncomfortable when you're sitting across the table from a client who outranks you. AI is not going to do this for you. An AI agent can surface information, generate options, and process data at a scale no human can match. It cannot sit in a room with a group of stakeholders who have conflicting priorities and figure out what needs to happen next. That still requires a person, and not just any person. ### **What this means in practice** I'm not suggesting you ignore Agentforce or stop learning about AI. That would be its own kind of career risk. The platform is moving, and you need to move with it (so do I, by the way). But the skills worth investing in most seriously right now are the ones that have probably been quietly undervalued for years. The ability to challenge a client constructively. To hold a line when you're being pushed to cut a corner. To communicate clearly when the news isn't good. These are not soft skills in the dismissive sense of the word. They are the hard part of the job. And they are, increasingly, the part that will probably matter the most. Pei's session was a good reminder of that. I went in looking for a technical roadmap and came out with something more useful: a prompt to think carefully about where the real investment should go. The irony is that none of this is new. It just takes an AI revolution to make people pay attention to it. --- ### Credibility compounds: Why admitting what you don't know builds more trust than bluffing URL: https://forcefields.tech/credibility-compounds-why-admitting-what-you-dont-know-builds-more-trust-than-bluffing/ Last updated: 2026-06-01T07:00:28.000Z *Bluffing your way through a knowledge gap might feel safe in the moment - but it quietly poisons the well for every confident claim you make afterwards. Here's why honesty about what you don't know is the fastest route to credibility that actually sticks.* --- Here is something that takes most consultants a while to learn: clients are not expecting you to know everything. They are, however, expecting you to be straight with them. Those are not the same thing, and conflating them is one of the more costly mistakes you can make in a client-consultant relationship. The instinct to bluff is understandable. You are paid to be the expert. Admitting uncertainty feels like undermining your own value. So you fudge it. You give a confident-sounding non-answer, or you quietly go away and Google something you should have known, or you frame a guess as a considered opinion. The client probably does not notice, at least not immediately. "Fake it 'till you make it", right? But here is what is actually happening. Every time you bluff your way through a knowledge gap, you are spending credibility you have not earned. And the interest rate on that debt can be brutal when the client pulls the curtain back and finds that empty space. ### The case for saying "I don't know (yet)" When a client asks about something you genuinely know little about, the right move is to say so. Plainly, without excessive qualification or apology. "I'm not sure about this - let me check and come back to you with options." That is it. No elaborate hedging. No pretending you have a view you do not have. Just an honest acknowledgement and a commitment to follow through. What this does, counterintuitively, is make your confidence on other topics more credible. If a client knows you will openly admit a knowledge gap, they can reasonably conclude that when you do express confidence, you mean it. You have shown them your signal is reliable. That is worth considerably more than the short-lived impression of omniscience. Credibility is not built by always having the answer. It is built by being consistently honest about when you do have the answer, and when you do not. Over time, that consistency compounds. Clients start to trust your read on things - not because you *are* infallible, but because they have learned that you do not pretend to be. ### Mistakes are not a special case The same logic applies when something goes wrong - and in a long engagement, something will. Maybe you introduced a bug during release management (I know I have). Maybe you misread a requirement and built something that did not match the client's intent (I did that). Maybe an assumption crept into the design that should have been validated first (I've definitely done this). These things happen on real projects, regardless of how competent the team is. The question is not whether mistakes will occur. The question is how you handle them when they do. The wrong approach is defensiveness - qualifying the mistake to the point where it barely sounds like one, or hunting for contributing factors that shift some of the responsibility elsewhere. Clients see through this, and it damages trust far more than the original mistake did. The right approach is to own it without drama. Acknowledge what happened. Describe the impact clearly. Explain the fix. State specifically what will prevent it from recurring. Then move on. "I made a mistake. Here is the impact, here is the fix, and here is how we will prevent it from happening again." That sequence matters. Impact first - because the client needs to understand the consequences before they can evaluate the fix. Then the fix itself. Then the prevention step, which is the part that some people skip and which is actually the most important signal you are sending. It tells the client that you have thought past the immediate problem to the underlying cause. ### Write it down Whatever the scenario - a knowledge gap, a mistake, a course correction - document it. The decision made, the trade-off accepted, the step taken to prevent recurrence. In plain language, accessible to anyone who picks it up later. This is not about creating a paper trail to protect yourself. It is about giving the client something tangible. A written record of how a problem was identified and resolved is far more reassuring than a verbal "we've sorted it“. It demonstrates that the issue was taken seriously and handled methodically, rather than patched over. This could go into the project RAID log, or just an email with all the relevant people cc'd. It also helps the next conversation. When a similar issue surfaces three months later - and in complex projects, patterns tend to repeat - you have a reference point. You can show that you recognised it, addressed it, and have prior analysis to draw on. That is a very different position than starting from scratch. ### What clients are actually measuring you on Clients are not measuring you against a standard of perfection. They gave up on that before they even hired you - if they ever held it at all. What they are measuring you against is reliability. Can they trust what you tell them? Will you surface problems early, before they become expensive? Will you handle setbacks in a way that protects the project rather than your own reputation? Honesty, consistently applied, is the shortest path to all three. Not honesty as a virtue - though it is that too - but honesty as a practical strategy for building the kind of relationship where a client will still back you when things get difficult. And they will get difficult. They always do. --- **P.S.** I turn 40 later this year (!) and I've been doing this for quite some time. It's easier for me to own a knowledge gap than it would be if I were 25 and six months into my first consulting role. When a seasoned consultant says "I don't know, let me come back to you," clients tend to read it as honesty. When a junior consultant says the same thing, there's a real risk the client reads it as incompetence. That's not a fair comparison - but it's often the reality. The credibility that makes this approach work has to be built first. You can't shortcut to it. A junior consultant probably needs to be more cautious about when and how they admit uncertainty, and more deliberate about pairing it with a demonstrated path to an answer. The underlying principle is the same, but the execution looks different depending on where you sit. I'm aware of the irony in a senior consultant writing a post about the virtues of admitting what you don't know. It's a bit like a millionaire explaining the merits of long-term investing to someone who can't cover rent. The advice isn't wrong, I don't think. It just lands differently depending on who's giving it - and I think that's worth naming. ### Agentic AI and the Art of Confident Wrongness URL: https://forcefields.tech/agentic-ai-and-the-art-of-confident-wrongness/ Last updated: 2026-05-31T22:55:18.000Z There is a version of automation I trust. It is boring, predictable, and I mean that as a compliment. A well-built deterministic automation - like Flow and Apex - does exactly what it was told to do, every time, in the same order, with the same logic. When it breaks, it breaks in ways I can trace. I can find the broken record, the failed condition, the mismatched field value. And I can fix it, document it, and move on. There is no ambiguity about what happened, or why (most of the time anyway). Agentic AI is something else entirely. And I find myself more sceptical of it the more I learn about it. A note before going further: I am not an AI researcher, and I have no deep technical background in how large language models are built or governed. My scepticism is informed by observation and pattern recognition, not by expertise in the internals. If I have got something wrong, I am open to being corrected. ### **What "agentic" actually means in practice** The appeal of agentic AI is real. Instead of building a rigid sequence of steps, you describe a goal and let the system figure out how to achieve it. The agent reads context, makes decisions, calls tools, takes actions - sometimes across multiple systems - and arrives at an outcome. It can adapt when things change. It can handle variation that would break a traditional automation. That sounds useful. In some narrow, controlled scenarios, it probably is. But the same quality that makes it flexible - the fact that it reasons its way to a conclusion rather than following fixed instructions - is also the thing that should give you pause. Because reasoning is not the same as being *right*. ### **The hallucination problem, at scale** Most people who have spent any meaningful time with large language models have encountered hallucinations. The model states something with complete confidence that is simply untrue. Not vague, not hedged - just wrong, and said as though it were obvious. In a conversational context, this is annoying. So fact-check it, you correct it, and you move on. But the blast radius is limited to the person reading the output. Now give that same model a set of tools. Let it query your CRM, update records, send emails, trigger downstream processes. Let it take actions based on its reasoning, not just generate text. Suddenly the hallucination isn't just a wrong sentence in a chat window. It is a wrong action in a live system, potentially at volume, before anyone has noticed anything is wrong. Add to this the effect of *compounding hallucinations.* Imagine a relay race of hallucinating agents, where one agent's hallucinations are passed onto the next agent, who/which (?) adds a hallucination of its own - and on it goes. This is not a hypothetical risk. It is the logical consequence of how these systems work. ### **Sycophancy is arguably worse** Hallucinations at least have the decency to be obviously wrong if you check. Sycophancy is more insidious. Sycophancy - the tendency of LLMs to agree with, validate, and mirror back whatever the user seems to want to hear - means that if you push back on the model's output, it will often cave. Not because *you* were right, but because you pushed. The model optimises for your approval and continued engagement, not for accuracy. In a consulting context, imagine what this means. A user asks an agent to analyse some data and suggest a course of action. The agent produces a recommendation. The user says "are you sure? I thought it would be the opposite." The agent, eager to please, reconsiders - and agrees with the user. Not because the evidence changed, but because the question changed. This is not a guardrail failure. This is the model behaving exactly as designed, just not in a way that is useful to you. ### **The guardrail question nobody answers clearly** Vendors will tell you that agentic AI comes with guardrails. I do not doubt that these guardrails exist in some form. What I have yet to see is a satisfying, transparent answer to the question of how they actually work and - more importantly - how they fail. Every guardrail is a constraint applied to a system that, by design, reasons autonomously. At what point does the guardrail catch a bad decision? Before the action is taken? After? Who decides what counts as a bad decision? How does the system distinguish between a legitimate edge case and a genuine error? What happens when the agent is confidently wrong, and the guardrail doesn't catch it because the output looks plausible enough? I am not suggesting these questions are unanswerable. I am suggesting that "we have guardrails" is not an answer to them. ### **The 'toddler with kitchen knives' problem** Agentic AI is, in many ways, an incredibly eager-to-please system operating in an environment it could never fully understand, with access to tools that can cause real damage, and an alarming tendency to project confidence regardless of competence. Toddlers are a bit like that too. They mean well and they try hard. They will hand you something sharp with the most sincere expression you have ever seen. You do not solve that problem by telling the toddler to "be more careful". You solve it by deciding very deliberately what they should and should not have access to - and by understanding that the responsibility for what happens next is yours, not theirs. The same logic applies here. Agentic AI is not inherently dangerous. But deploying it without a clear-eyed understanding of how it fails, and who is accountable when it does, is not innovation. It is optimism at scale. And optimism is not a governance strategy. --- ### Headless 360 + Agentforce: A few questions nonprofit leaders should be asking URL: https://forcefields.tech/headless-360-and-agentforce-a-few-questions-nonprofit-leaders-should-be-asking/ Last updated: 2026-05-31T22:53:47.000Z If you've had a Salesforce conversation recently, you may have heard the phrase "[Headless 360](https://www.salesforce.com/blog/headless-360-integration-architecture/?ref=forcefields.tech)". It might sound a bit like a skateboard stunt, but in this context it refers to a genuine and relatively straightforward architectural concept: decoupling Salesforce's data layer from its user interface, so that other applications - custom portals, mobile apps, third-party platforms - can interact with your data directly, without going through the standard Salesforce front-end. On its own, that's a reasonable engineering pattern. It's been common practice in software development for years, and there are legitimate use cases for it. This is not, in itself, the thing I want to scrutinise. What *is* worth scrutinising is the way Headless 360 is currently being marketed - [almost always in the same breath as Agentforce](https://www.salesforce.com/uk/news/stories/salesforce-headless-360-announcement/?ref=forcefields.tech), Salesforce's agentic AI platform. The implicit message is this: if you don't need a human sitting in the interface, an agent can handle that interaction instead. Headless architecture enables it, and Agentforce delivers it. Efficiency unlocked, right? For a certain kind of organisation, that's an exciting proposition. For a nonprofit, I'd argue it deserves considerably more pause than it might get. ### **The higher bar nonprofits should be holding themselves to** Nonprofits exist to serve a community. Their legitimacy - and in many cases their income - depends on the trust of supporters, beneficiaries, and the public. That's a different operating context from a retail store or a logistics company. The calculus around automation isn't just "does this save time?" It should also be "is this consistent with who we say we are?" When a long-standing donor calls your organisation, or a beneficiary reaches out in a moment of need, the experience of that interaction carries meaning beyond its transactional content. It signals whether your organisation sees them as a person or a data point. Automating that interaction entirely - replacing a human on the other end of the conversation with an agent that processes, responds, and closes the loop with little to no human involvement - is a choice. And it's a choice that sits in direct tension with the language most nonprofits use about their relationships with the people they serve. This doesn't mean agentic AI has no place in a nonprofit. It clearly does. Processing gift aid claims, flagging lapsed donors for a human to follow up, triaging high volumes of inbound enquiries so your team can focus on the conversations that genuinely need them - these are reasonable applications. The technology is expanding your team's capabilities. That's a legitimate use of it. The line I'd encourage nonprofit leaders to draw - clearly, and *before* the technology is in the room - is between using AI to increase what your team can do, and using it to reduce the number of people doing it. Here is the uncomfortable version of that point: the two outcomes aren't always as separable as they look on a slide. ### The line that moves on its own If agentic AI handles a meaningful proportion of inbound supporter contact, your organisation may not make anyone redundant today. But when someone leaves that team, the case for replacing them becomes harder to make. The headcount reduction doesn't arrive as a purposeful decision - it arrives as a series of individually reasonable non-decisions. Attrition does the work quietly, and by the time anyone notices how small the team has become, the technology has already been normalised. I don't think this is a hypothetical. It is a predictable consequence of deploying automation without defining, in advance, what you're actually trying to achieve with it. ### **Test it against your mission statement, not the demo deck** The most useful governance question for any nonprofit considering Agentforce - or any agentic technology, Salesforce-adjacent or otherwise - is not "can we implement this?" It's "does this align with how we say we treat the people we exist to serve?" Your mission statement exists for a reason. It describes, in terms your organisation has publicly committed to, what you stand for and how you operate. Before any agentic capability goes near a supporter-facing process, it should be tested against that statement. Not the vendor demo. Not the business case built around efficiency savings. Your mission statement. If your organisation says it builds genuine relationships with its community, and you're about to replace a meaningful part of that community's human experience with an automated interaction, those two things deserve to be discussed in the same room at the same time. If the people signing off on the technology decision are different from the people who wrote the mission statement, that's a conversation worth having before releasing the agent(s). ### **A few questions worth sitting with** 1. Would your supporters be comfortable knowing their interaction was handled entirely by an agent - and have you considered asking them? 2. Is the efficiency case for this technology being made by the same people who will be measured on cost reduction? 3. If your organisation deployed this fully and it worked exactly as promised, what does your team look like in 3-5 years - and is that the organisation you set out to build? None of these questions have obvious answers. That's rather the point. Headless 360 is a technical pattern. Agentforce is a product. How they get used in your organisation is a values decision - and it should be treated as one. --- ### If your client makes all the decisions, what do they need you for? URL: https://forcefields.tech/if-your-client-makes-all-the-decisions-what-do-they-need-you-for/ Last updated: 2026-05-31T22:52:10.000Z If your client makes all the decisions, what do they need you for? That is the question I come back to every time I feel the pull to just go along with something. It is a potentially uncomfortable question. Consultants - especially those early in their careers - often conflate agreement with professionalism. The client is paying for your time. They know their organisation. Pushing back feels presumptuous, maybe even rude. "*The customer is always right*" - aren't they? Check out [my intro post](https://forcefields.tech/salesforce-wasnt-my-plan/) to find out what I think about that sentiment. There is a difference between respecting a client's expertise and abdicating your own. The consultant who mostly executes what they are told will, over time, train their client to stop asking for input. Once that happens, the relationship shifts. You are no longer a trusted adviser. You are a pair of hands. Easily replaced. To be clear; I'm not advocating for combative posturing. If you routinely reject their input I can guarantee they'll stop asking for your input too. I'm merely suggesting that you adopt a healthy portion of scepticism. ### **The compliance trap** The irony is that saying yes feels like good service. It feels collaborative. It avoids conflict. And in the short term, it usually does keep the client happy. But "happy now" and "well-served" are not the same thing. A client who makes a poorly informed decision - because their consultant did not challenge it - will eventually realise that. They may not blame you explicitly. But they will stop calling you first. The consultants who build long-term relationships are the ones clients trust to tell them something they do not want to hear. ### **A framework worth keeping** When I need to push back, I use a three-part structure: **Evidence, Empathy, Option.** **Evidence** is what the data or constraints actually show. Not your opinion - the facts on the ground. This is what makes the pushback credible rather than merely opinionated. **Empathy** is acknowledging why the client's instinct made sense. Their request did not come from nowhere. There is usually a legitimate concern underneath it - cost, timeline, organisational politics, a bad experience with a previous tool. Name it. Show you understand it. **Option** is the alternative path. Not a vague suggestion that they should reconsider - a concrete, better-founded direction. Something they can actually choose. I often open with: *"I would like to explore this a bit further, if I may."* It signals challenge without aggression. It invites rather than confronts. ### **In practice** Here's an example of using the Evidence-principle. I was working on a project a while back. We were at the tail end of an 18-month development phase - UAT was imminent - when the client raised a request for an additional, fairly complex use case. Late-stage scope additions are one of the more reliable ways to derail a delivery. I had three options. Try to squeeze it in and accept the risk. Tell them the timeline would need to move. Or challenge whether the request was as necessary as it felt in the moment. I chose the third option. The use case had the feel of an edge case - something that had surfaced once or twice and lodged itself in someone's mind as a problem worth solving. Rather than dismissing it, I asked a simple question: "Out of roughly 30,000 supporter interactions last year, how many of them actually involved this use case?" The data existed in their current CRM system, but pulling it would take effort. When faced with that request, the client paused - and then dropped it. The use case was not important enough to justify with evidence. It probably never was. That is what challenging the premise can look like. Not "we cannot do this" - but "can we establish whether we should?" ### **The principle** Clients hire consultants for expertise, not compliance. They can make decisions themselves - they do it every day. What they cannot always do is see the full picture, weigh options they have not considered, or challenge their own assumptions with the benefit of cross-sector experience. That is your job. If you are mostly just doing what you are asked, you are not doing your job - you are doing their admin. Push back. Professionally, constructively, with evidence. But push back. --- ### Salesforce Wasn't My Plan URL: https://forcefields.tech/salesforce-wasnt-my-plan/ Last updated: 2026-05-20T11:55:19.000Z Salesforce wasn't my plan. But it became my professional anchor point. When I was a 'tween' I thought I wanted to be a fighter jet pilot. Later I thought I was going to be a fulltime musician (I wasn't sufficiently talented or driven for that though). In 2006, fresh out of secondary school in Copenhagen, I took a job in telemarketing. Not a vocation - just something to do. But I liked my manager, and when she moved to a pension company to build a new department, I followed her. I was 21, knew nothing about pensions or insurance, and had no particular plan beyond showing up. I spent four years in that inbound customer service team. The path being laid out for me pointed clearly toward becoming a pension insurance salesperson. I hated that idea. What I actually liked - what kept pulling my attention - were the projects happening around the edges. IT projects, process improvement work, anything that involved finding a better way of doing something. My manager at the time noticed it before I did. "You have a natural propensity for project work," he told me. I didn't fully understand what he meant at the time. I think he meant that I couldn't help looking at broken things and wanting to fix them. I became the department's unofficial techie, which later turned out to be rather useful. ### **The accidental BA** In 2010 I transitioned into the IT department as a newly minted business analyst. I wasn't entirely sure what a business analyst was. My first assignment was to help deliver a new Salesforce implementation for the sales team. Nobody in the company had any Salesforce experience. We had no implementation partner. We were all learning by doing, which mostly meant learning by getting things wrong and trying again. It took two years to reach a beta release with twelve internal users, and another full year before we went live with a hundred. By most measures, it was a difficult project. But two things happened during those three years that shaped everything that followed. The first was that Salesforce clicked for me quickly. The technical side - the configuration, the logic of the platform - made intuitive sense in a way I hadn't expected. I went from writing user stories and drawing process diagrams to building workflow rules and validation rules, and I wanted to know more. The second was that I got to watch two project managers work side by side, and they could not have been more different. One became my mentor. She was a superb communicator, politically sharp, and completely comfortable calling people out when they were wrong - including upward. She had no interest in performing competence. She just had it. The other taught me everything about how not to run a project. He was obsessed with appearing to be on top of things, especially in front of senior leadership. He couldn't challenge anyone above him, couldn't admit fault, and produced almost nothing of practical value despite talking constantly. He had confused *looking* capable with *being* capable (if you're reading this, I'm sorry for putting it this way - but it taught me a lot, so I'm also grateful). I was in my mid-twenties, and I was watching those two approaches play out in parallel in real time. It stuck. ### **A detour through Nairobi** In 2013, I enrolled in a graduate diploma programme at the [IT University of Copenhagen ](https://en.itu.dk/?ref=forcefields.tech)\- a way of building some theoretical foundation under what had become a practical career. But before I could graduate, I needed a thesis subject. In 2015, on a private trip to Kenya, I met people connected to an organisation called [Human Needs Project](https://www.humanneedsproject.org/?ref=forcefields.tech), based in Kibera, Nairobi. They deliver clean water, vocational training, and various community services to one of the largest informal settlements in Africa. One of those services is microfinance - small loans and savings for over a thousand people, tracked at the time in a tangle of unstructured Excel sheets. They heard I worked in IT. They were enthusiastic in the way that people are when they genuinely need help and haven't had much of it. I listened, asked questions, and told them I'd see what I could do. A few months later I had a thesis subject. I got approval to use Human Needs Project as my case study, designing a new system to manage their microfinance operation. After I graduated, I kept going - voluntarily, remotely. I built the Salesforce solution, recorded training videos, iterated based on their feedback. The system went live in 2016. They still use it today. That experience - more than anything else - is why I work with nonprofits. Not as a brand positioning exercise, but because I had already seen what it looked like when a mission-driven organisation got the right tools and the confidence to use them. ### **London, and finding the right fit** By 2016, after a year managing the same Salesforce org week after week, I was restless. I still loved the platform. I just needed a bigger pond. London had more opportunities, so I moved (side note; I received my job offer the morning *after* the Brexit vote, literally on 24th June 2016 - talk about a weird omen!). ![A man in the foreground with Thames river and the Shard building in the background](https://storage.ghost.io/c/60/fe/60feeaea-39c9-4d74-a7a4-5e9fc440ecf0/content/images/2026/05/LDN-1.jpg) By the Thames less than a month after moving to London in 2016 My first consultancy role didn't last long. The work was entirely commercial, the firm was heading into a large merger, and neither felt like somewhere I could build something meaningful. After seven months I left. My team leader there - to her credit - recognised the mismatch. She connected me with the managing director of [Giveclarity](https://giveclarity.org/?ref=forcefields.tech), a Salesforce partner working exclusively with nonprofits. I joined in 2017, and I'm genuinely happy there. ![A man and a golden retriever posing for an upclose "wefie". The dog is "smiling", as is the man.](https://storage.ghost.io/c/60/fe/60feeaea-39c9-4d74-a7a4-5e9fc440ecf0/content/images/2026/05/Marley-5.jpg) Marley and I on a morning walk in Richmond (UK) in 2019 ### **When someone names what they see in you** During my first annual review at Giveclarity, my line manager said something that I've carried with me since. "When you speak," she told me, "you speak with a certain authority, with gravitas - and it makes people pay attention." I was 31\. Still relatively green as a consultant. And it was the first time I properly understood that the way I showed up in a room was doing something - not just what I said, but how I said it. It wasn't arrogance or performance. It was just being clear about what I thought and saying it without reservations or apology. That's what this site is about. I've spent the years since leading implementations for organisations like Save the Children, UNICEF, and Médecins Sans Frontières - large, complex projects where the margin for error is real and the stakes matter. I've developed a fairly clear picture of what good delivery looks like, and equally clear picture of what gets in the way of it. What gets in the way, more often than technical gaps, is confidence. Junior consultants who know the right answer but won't say it because they're worried the client will push back. Experienced consultants who let clients take the wheel because confrontation feels risky. The slow drift away from good practice because nobody wanted to be the one to hold the line. I'm writing here because I want to push back on that drift - and because I think more people in this field are capable of holding the line than they currently believe. ### A word of balance One thing worth saying clearly before we go any further: none of this is an argument for arrogance. The goal is not to create consultants who are combative, who dig in on principle, or who mistake stubbornness for expertise. Clients know their organisations better than we ever will, and that knowledge deserves genuine respect. But there is an old saying that has done a fair bit of damage in various service industries: "*the customer is always right".* What people forget - or never knew - is that the full saying is "*the customer is always right in matters of taste".* Taste. Preference. Colour schemes and naming conventions, and whether the dashboard goes on the left or the right. Not architecture. Not data integrity. Not whether a process that will cause problems in six months should be built because the client wants it now. The default position should not be deference. It should be honest, well-reasoned professional judgement - delivered with respect, and held with confidence when it matters. That's the balance worth aiming for. If any of that resonates, you're in the right place.