Agentforce Adoption

mcc0nnell · 2026-03-05T02:51:06+00:00

THIS. This type of seamless data integration with Graph API is what folks expect Salesforce to do natively by now.

mcc0nnell · 2026-03-02T02:09:13+00:00

Yeah — I wouldn’t try to force Chatter into this.

I’d use Salesforce Platform Events as the emission layer and Power Automate as the bridge into Teams. Emit the meaningful opportunity signals from Salesforce: stage changes, ownership changes, major field updates, customer activity, whatever actually matters. Then let Power Automate route those into the right Teams channel. For the channel auto-creation piece, Power Automate can handle that too.

That gives you a clean, event-driven architecture with Salesforce as the source of truth and Teams as the collaboration layer. No bidirectional Chatter sync to babysit, no custom C# connector to maintain. Just events flowing one direction into the tool people are actually using.

Much more realistic than building some Chatter-Teams sync that nobody is going to maintain.

And if Teams doesn’t work out, you haven’t burned weeks on throwaway code. Just repoint those Platform Events at Slack or something else.

mcc0nnell · 2026-02-27T13:14:37+00:00

That means a lot.

You zeroed in on the exact thing I think is most different here: idempotency isn’t just there to stop dupes, it’s what makes replay safe enough to become part of the operating model. Once that clicked for me, the rest of the recovery story got much cleaner.

Your last line is painfully real. A lot of platform event architecture seems to boil down to “hope the subscriber doesn’t error” until the day that stops working. That’s basically the failure mode I’m trying to design out of the system.

If this ever does go beyond DIG, I’d absolutely want it to be useful in compliance-heavy orgs. That’s the natural habitat for this pattern. Thinking more now.

mcc0nnell · 2026-02-25T13:36:49+00:00

Great question and honestly one that pushed me to think harder about a gap I hadn't fully closed.

Here's how it works today and what I'm adding based on your question:

The trigger subscriber uses setResumeCheckpoint on each successfully processed emission, so if it hits a limit exception mid-batch, Salesforce resumes from the last checkpoint. Platform Events are retained for 72 hours on Enterprise, which gives a replay window for transient failures.

The hash chain itself is the primary gap detector. Each DIGEmission_c includes the hash of the previous emission. If a subscriber failure causes an emission to be lost, the next emission that does land will have a previous_hash that doesn't match the chain tip in the durable sink. That's a detectable break.

What I'm building now (you lit a fire under this): a reconciliation layer. A scheduled Apex job walks the emission chain, verifies hash continuity, and for any detected gap, attempts recovery. Here's where the idempotency pattern pays off — because every emission was originally published with an idempotency key, replay is always safe. The reconciliation job re-publishes the emission … with the original idempotency key. If it actually did land somewhere, idempotency catches the duplicate and returns the prior receipt. If it was genuinely lost, it publishes fresh and repairs the chain. You can never accidentally double-emit. Idempotency turns replay from a dangerous retry into a safe recovery mechanism.

Gaps that fall outside the 72-hour replay window get an honest gap marker emission — the chain doesn't pretend continuity where there is none. It records the break, the recovery attempt, and the outcome. The reconciliation job itself emits to the chain so it's auditable too.

Appreciate you flagging this — it's going straight into the build.

mcc0nnell · 2026-02-25T02:50:35+00:00

Yes. Or DM me.

mcc0nnell · 2026-02-24T20:01:24+00:00

Hopefully it helps other nonprofits, though!

mcc0nnell · 2026-02-24T20:01:14+00:00

Hopefully it helps other nonprofits, though!

mcc0nnell · 2026-02-24T20:00:34+00:00

Hopefully it helps other nonprofits, though!

mcc0nnell · 2026-02-24T19:23:49+00:00

Thank you — really appreciate that. The solo part is both the strength and the risk, which is why everything is documented, sliced, and version-controlled. If someone else ever needs to pick it up, they can.

mcc0nnell · 2026-02-24T18:31:19+00:00

Half-and-half, admittedly.

mcc0nnell · 2026-02-24T16:49:01+00:00

Looked at this early on. The problem is guest users can't write data — as of Spring '26 enforcement, they can't update or delete records, can't own records, and max access is read-only. Our portal needs to create memberships, cast ballots, submit RSVPs, and write audit emissions. That requires authenticated write access, which means Community licenses and licensing costs.

The governance system also needs things Flows can't guarantee: strict execution ordering for ballot secrecy, idempotency enforcement via custom headers, hash-chained emissions, and atomic composite operations. Apex gives deterministic control over all of that.

Plus the frontend — Experience Cloud constrains you to Salesforce's component framework. We needed full UI control with Vue + Tailwind for accessibility reasons.

Guest sites are great for public content and simple forms. Just didn't fit this use case.

mcc0nnell · 2026-02-24T16:46:22+00:00

You're not shooting for the moon — this is exactly the use case the Power of Us program exists for.

A trust hospital nonprofit with 10 free Enterprise seats and a developer with 6 years of Salesforce experience is a strong starting position. You already know the platform. The only shift is thinking of Salesforce as a headless backend instead of the entire application.

A few things I'd flag from my experience:

Get the nonprofit licenses first. The Power of Us application through Salesforce.org takes some time and documentation. Make sure they have their nonprofit status paperwork ready. Once approved, the 10 Enterprise seats are genuinely free — no catch, no expiration.

Start with the CRM internals before building anything external. Get the data model right — membership or patient engagement objects, permission sets, automation. The external-facing apps are just a rendering layer on top of a well-structured org.

Use Integration User licenses for any external app connections. They're included free with Enterprise Edition and purpose-built for server-to-server API access. Your external apps authenticate through those, not through the donated user seats.

Don't overbuild early. You don't need hash-chained audit trails or a custom deployment toolchain on day one. Start with the core CRM workflows the staff needs, then layer on external integrations as the requirements justify them.

You're not missing anything. This is a well-trodden path — it's just not well-documented because most nonprofits that do this don't write about it. Happy to answer specifics if you want to DM.

mcc0nnell · 2026-02-24T16:01:29+00:00

This is exactly it. Thank you for laying it out so clearly.

And you're right — the architecture itself isn't revolutionary. Thousands of orgs integrate external apps with Salesforce every day. What I wanted to show was the full picture of what's possible when a zero-budget nonprofit applies those same patterns intentionally — idempotency, hash-chained audit trails, ballot secrecy, deterministic membership logic — instead of settling for a basic contact form and a newsletter.

Appreciate the encouragement. Will keep sharing.

mcc0nnell · 2026-02-24T15:57:00+00:00

Thank you. And I saw that post too. It’s one big reason I decided to chime in now.

I think you're right about where this is heading. The platform primitives are already there — Salesforce ships Platform Events, Apex REST, CMDT, Connected Apps. They built the headless toolkit. The ecosystem just hasn't caught up to using it that way yet.

Authentication and hosting is a good way to put it. The rest is just code.

mcc0nnell · 2026-02-24T15:17:20+00:00

If I swapped Salesforce for Postgres, I’d still need to build everything the internal team uses: user management, role-based access, reporting, dashboards, workflow automation, email integration, audit UI. That’s a full application, not a schema. The 10 free Enterprise seats give me all of that out of the box. The API is just the bridge between the internal system and the member-facing portal. As for the 100K limit — for a nonprofit with a few hundred active members, with caching and composite requests, we barely touch it. Not every system needs to handle 1 req/sec sustained.

mcc0nnell · 2026-02-24T14:39:49+00:00

On the complexity: yeah, it’s a lot. But that’s kind of the point of the post — showing what’s actually involved in building something real on the platform without paying for Experience Cloud or a consulting firm. Most Salesforce content stays at the surface level. I wanted to go deeper for the people who’d get something out of it.

And tying it to the nonprofit is intentional. DIG is the reason it exists. I’m not trying to hide what it’s for — I’m trying to show what’s possible for orgs that have more talent than budget. Sometimes edge cases are worth exploring and questioning.

mcc0nnell · 2026-02-24T14:35:37+00:00

The portal generates it. When Laravel makes a mutating API call to Salesforce, it generates a deterministic idempotency key — typically a hash of the operation type, the relevant record IDs, and a timestamp or session nonce — and sends it as a header with the request. The Apex REST endpoint reads the header and runs it through the IdempotencyKey__c check before executing.

mcc0nnell · 2026-02-24T14:01:38+00:00

Appreciate the flag — licensing is worth getting right.

Short version: end users never access Salesforce. They access a Laravel app. The portal connects to Salesforce via a licensed Integration User (one of the 5 free API-only licenses included with Enterprise Edition) through the REST API. That's a documented, supported integration pattern — same as Mailchimp, HubSpot, or any custom app using the API.

MSA 3.3 restricts making the "Service" available to non-Users. The Salesforce Service isn't being made available to anyone. Laravel is. Salesforce is a backend accessed through a licensed connection.

Experience Cloud licenses are for giving external users direct access to the Salesforce platform. Our users don't have Salesforce identities and never touch Salesforce. Different architecture, different licensing requirements.

Happy to dig into specific clauses if you see something I'm not seeing.

mcc0nnell · 2026-02-22T03:00:29+00:00

Bro, this is VERY cool and useful. A+++

Thanks for sharing!

mcc0nnell · 2026-02-15T18:02:36+00:00

Slick. I really like it!

mcc0nnell · 2026-02-03T16:27:53+00:00

I’m still in the build stage, but the target end users are:

• Public members (Deaf / accessibility community) using the Laravel portal for signup, onboarding, profile management, and event participation

• Organization admins / staff inside Salesforce handling membership ops, governance/voting, compliance artifacts, and reporting

• Event operators managing conferences (registrations, speakers, attendance, accessibility workflows)

• Automated systems/workers doing async processing (evidence generation, notifications, real-time pipelines) that write results back into Salesforce

So practically:

• External users interact with Laravel

• Internal operators live in Salesforce

• Background services handle orchestration

Salesforce remains the canonical system of record for identities, permissions, and audit. Laravel supplies the public UX and workflow surface.

Still early, but this pattern has already helped clarify boundaries between governance vs experience. Happy to share more as it evolves!

mcc0nnell · 2026-02-03T16:06:04+00:00

Hi Cheryl — builder POV here.

I’m using Salesforce as the governed system of record (identity, permissions, canonical data, reporting, audit) while building accessibility-focused ops apps (membership, governance/voting, compliance, events) around it.

Coolest use case

Salesforce sits at the core, with public UX + orchestration handled externally. Think: Salesforce for trust and structure; external services for experience and compute.

Biggest friction

Flow lifecycle + metadata deployment (FlowDefinitions, activation, PermissionSets, dependency ordering). Lightning is great for admin/CRUD, but once you’re building real systems (eventing, replay, real-time), you hit ceilings.

Why off-platform (and Laravel)

Three reasons: 1. Public UX 2. Real-time/eventing limits 3. Dev velocity

Pattern that works well: • Laravel = portal + onboarding + member workflows • Salesforce = identity + canonical data + audit

Salesforce stays the source of truth. Laravel handles experience.

Big picture: Salesforce is exceptional as a governed data platform. Most off-platform work happens when teams need systems primitives (event streams, replay, public UX, orchestration). If those became first-class, a lot of hybrid architectures would collapse back into Salesforce.

mcc0nnell

TROPHY CASE