Category: For Fun

Stop Wrestling With Your Salesforce Org: How ApexGenius Turns Technical Debt Into Clarity in Minutes

Unlock the hidden potential of your Salesforce org with ApexGenius. Simplify documentation, streamline workflows, and deploy changes effortlessly through chat. Experience the power of AI-driven clarity and efficiency today.

You know the feeling. You’ve inherited a Salesforce org that’s grown organically over years. Dozens of Flows. Hundreds of validation rules. Apex classes that reference other Apex classes that connect to Flows that nobody quite remembers. You’ve got a feature request that should take two hours but turns into two days of archaeological work just to understand what’s already out there. And don’t even ask how to document any of it.

Welcome to the technical debt problem that’s quietly becoming the biggest bottleneck in Salesforce administration in 2026. And it’s about to get harder, not easier — because the same AI tools that promise to speed up your Salesforce work (Agentforce, Einstein, and others) can’t function reliably on poorly understood, fragmented orgs. You need clarity first. You need ApexGenius.

The Problem Nobody Wants to Admit

Let’s be honest: most Salesforce orgs are undocumented. Spreadsheets decay. Confluence pages get outdated the moment someone tweaks a Flow. That “Where is this used?” button in Setup only goes so far. The result? When you need to build something new, audit what exists, debug a broken automation, or onboard someone new, you’re stuck doing detective work instead of real work.

This is why solo admins feel like a single point of failure. Why developers on large teams spend half their time mapping dependencies in their heads. Why consultants juggling five orgs at once have to keep the system architecture alive entirely in memory — until they don’t.

The fix has traditionally been: hire someone dedicated to documentation. Or spend weeks in a Lucidchart. Or hope the previous owner left notes.

Until now.

Meet ApexGenius: Your Salesforce Org Explained in Plain English

ApexGenius connects to your Salesforce and helps you understand how your sales processes work. Generate documentation, converse with your data, and deploy changes — all through chat.

The key word there is chat. Not clicking through Setup. Not opening VS Code. Not running CLI commands. Just talking to your Salesforce org like it’s a colleague who understands every line of code and every workflow inside it.

Here’s how it works:

1. Connect Once, Understand Everything

You authenticate ApexGenius to your Salesforce org (we recommend starting with a sandbox). The tool ingests your entire metadata landscape: Apex classes, Lightning Web Components, Flows, validation rules, custom objects, permission sets, and more. Think of it as giving the tool the complete architecture of your org in one shot.

2. Ask Your Questions in Plain English

“What does the Quote Approval Flow do?”
“Show me everywhere the Account-triggered Apex is used.”
“Generate documentation for the CalculatePrice class.”
“What are all the open leads in the EMEA region?”

ApexGenius understands these questions—and answers them. No query language required. No Setup navigation. No guessing about what you’re looking for. It’s like having a Salesforce architect sitting next to you who’s read every line of your org’s code.

3. Build, Deploy, and Document—All From Chat

Here’s where it gets powerful. ApexGenius doesn’t just understand your org—it can change it. You can ask it to build a permission set, deploy it to your org, and assign it to a user—all without leaving the chat. No Setup clicks. No VS Code. No CLI. Just conversational, action-oriented work.

Three Problems It Solves (At Once)

Problem 1: Undocumented Orgs Are Unmaintainable

You can’t move fast in a system you don’t understand. ApexGenius auto-generates documentation for your components, transforming Apex classes and Flows into written explanations that your team can actually read and act on. No more asking “Why is this here?” because the tool has answered it.

Problem 2: Data Queries Bottleneck Non-Technical Teams

Salesforce’s power has always lived in the hands of developers and admins who write SOQL. Meanwhile, managers and ops teams ask questions but can’t get answers. ApexGenius translates natural language into SOQL queries on the fly—meaning your entire team can pull data without waiting for a developer to write a report.

Problem 3: Delivering Org Changes Is Slow

A permission set should take five minutes to create. Instead, you’re navigating Setup, hunting for the right object permissions, double-checking access levels, and testing. ApexGenius handles it in chat: you describe what you need, it builds it, deploys it, and documents what it did. Hours compressed into minutes.

Who Should Use This?

ApexGenius was built for three groups:

  • Solo Admins: You’re the system of record for your org. You don’t have time to become a documentation specialist, but you can’t afford to let technical debt pile up. ApexGenius is your force multiplier.
  • Developers on Larger Teams: You get requests to understand what’s already built, debug someone else’s code, or document existing work. ApexGenius does that research in seconds.
  • Salesforce Consultants: You’re constantly jumping between orgs. Each one is a unique snowflake. ApexGenius brings you up to speed fast, helps you document your work, and lets you build and deploy faster than ever before.

Getting Started: The Smart Way

ApexGenius offers a generous free tier: 25 AI queries per month. That might sound modest, but it’s plenty to test whether it works for your most painful use case. Here’s what we recommend:

  1. Start with a sandbox. (Not production. Not yet.)
  2. Pick your hardest documentation problem. That undocumented Flow. That Apex class that nobody understands. That critical automation that’s supposed to be deprecated but nobody dares touch. Point ApexGenius at it and ask for an explanation.
  3. See what it generates. Is it accurate? Does it save you time? Does your team understand the explanation?
  4. Expand from there. Once you’ve seen the value, you’ll know whether you want to commit to a paid plan or try deploying changes through it.

The barrier to entry is zero. The potential upside is hours of your time every single week.

Why This Matters Right Now

Technical debt in Salesforce has become critical. It’s not just slowing down your team—it’s actively blocking the AI-powered features you’re trying to adopt. Modern AI tools like Salesforce’s Agentforce can’t function reliably on messy, undocumented orgs. You need a clear, mapped, understood foundation first.

That’s what ApexGenius gives you. Not just a tool, but a path out of the technical debt trap.

Your Next Step

Head over to www.apexgenius.ai and sign up for the free tier. Connect your sandbox. Ask one question. See for yourself why admins, developers, and consultants are already using ApexGenius to reclaim their time and take back control of their Salesforce orgs.

The orgs that thrive in 2026 will be the ones that made clarity a priority. ApexGenius makes that possible.

Have you dealt with the technical debt trap? What’s your biggest pain point when managing a complex Salesforce org? Drop a comment below—we’d love to hear your story.

Introducing CairnCI: A Modern, Open-Source Salesforce Deployment Pipeline

CairnCI is an open-source CI/CD pipeline for Salesforce DX, designed to automate the validation and deployment of changes. Built on GitHub Actions, it bridges the gap between Salesforce’s native tooling and code-first workflows, providing a community-maintained reference implementation that simplifies CI/CD for teams.

So. Change sets. We need to talk about change sets.

We’ve all been there. You’ve got a sandbox full of beautiful, carefully crafted metadata, a team that’s ready to ship, and then… you’re staring at the Change Set screen clicking individual components like you’re defusing a bomb. Except the bomb isn’t optional, and it definitely doesn’t care about your timeline.

If you’ve spent any time in the Salesforce ecosystem, you know the pain. Salesforce DevOps Center was a real step forward — and I’ve written about it before — but it’s still a Salesforce-native tool with Salesforce-native constraints. For teams that have grown into a more code-first, source-driven workflow, or who have specific governance requirements their org doesn’t bend to meet, there’s a real gap in the tooling available. Especially when it comes to CI/CD.

That gap is what CairnCI is trying to fill.

What is CairnCI?

CairnCI is an open-source CI/CD pipeline for Salesforce DX, built on GitHub Actions. It’s designed to be plugged into a Salesforce DX repository and handle two core things automatically:

  • Validate on every pull request — runs a delta-only, check-only deployment against your org using RunLocalTests, so your team knows before anything merges whether the changes will actually deploy.
  • Deploy on merge — maps branches to environments, reuses the validation job-id from the PR for a quick deploy (because running all your tests again immediately after you just ran them is a special kind of tedious), with an automatic fallback to a full deploy if the validation has expired or isn’t available.

The name comes from the idea of a cairn — those stacked stone trail markers that hikers build to mark the way forward in terrain where the path isn’t obvious. That felt right. Salesforce DevOps can be a lot of terrain.

Why build this?

Honestly? Because I’ve set up enough Salesforce CI/CD pipelines from scratch to know that everyone is solving the same problems in slightly different ways, and most of the solutions are locked inside someone’s private company repo.

The Salesforce ecosystem has a lot of great individual tools — the sf CLI, sfdx-git-delta, GitHub Actions — but there isn’t really a good, community-maintained reference implementation that ties them together in a way that’s ready to adopt. So I built one, and I’m putting it out in the open so other teams can use it, adapt it, and (hopefully!) contribute back to it.

The goal isn’t to be a black box. CairnCI is designed to be extensible and transparent — you can see exactly what it’s doing, pin it to a specific version, and override its behavior through inputs or a committed config file.

Who is it for?

If you’re running a Salesforce DX project with your metadata in source format and you’re using GitHub, CairnCI is probably useful to you. In particular:

Developers and admins who are tired of manual deployments. If you’re still clicking through Change Sets or running sf project deploy by hand every time someone wants to push code, CairnCI automates that entire loop from PR to production.

Teams that want to adopt modern DevOps practices without building everything themselves. You don’t need to write and maintain your own GitHub Actions workflow from scratch. CairnCI gives you a starting point that already handles the tricky bits.

Organizations with compliance or security requirements. There’s a “vendor” adoption path specifically for air-gapped or strict-security environments where every line of executed CI code needs to live in your own repository, reviewed and pinned — no external action references at runtime. This one comes up a lot in government and regulated industries.

The two ways to adopt it

CairnCI supports two adoption paths, and the choice really comes down to how much control you want over the pipeline code:

Path A (Recommended for most teams): Reference a pinned version. Your repo adds a few small caller workflows, and the heavy lifting stays in CairnCI. When CairnCI releases an update, you bump a version tag. Your .cairnci/config.json file controls which features run and how. This is the “lean” option — minimal code to maintain, easy updates.

Path B: Vendor a pinned version into your repo. You copy the pipeline code directly into your own repository. From that point on, CairnCI isn’t an external dependency — everything runs locally from your repo. This is the right choice if your organization’s policy requires that every line of executed CI code is reviewed and committed in-repo. Re-running an update means copying a new tagged version and reviewing the diff in a PR.

Both paths support the same feature set.

The field governance gate (my personal favorite)

One of the things I’m most proud of in CairnCI is the optional field permission-set governance gate. This one takes a little explaining, but stay with me.

When you add a new field to a Salesforce object, it doesn’t automatically become accessible to anyone. Someone has to wire up permission set access, or the field just… sits there, invisible to your users. And in a team environment, it’s surprisingly easy for that to slip through code review. You’re looking at the field definition, you’re checking the Apex tests, and nobody notices that there’s no permission set entry for it.

The field governance gate catches that at the pipeline level. Before a PR can merge, it checks that any new fields in the changeset have the appropriate permission set access configured — and optionally, that they include required governance metadata. If they don’t, the gate blocks the deploy and tells you exactly what’s missing.

It’s the kind of thing that saves a lot of “wait, why can’t users see the new field?” tickets.

What it’s built on

CairnCI is built on tools that are well-maintained and widely used in the Salesforce developer community:

  • The modern sf CLI (not the legacy sfdx) for all Salesforce operations
  • sfdx-git-delta for generating delta packages — only deploying what actually changed, not your entire source directory every time
  • GitHub Actions for the automation layer
  • GitHub Environments for secure org credential management and deployment protection rules

All of the toolchain versions (Node, the SF CLI, sfdx-git-delta) are pinnable, so you’re not at the mercy of whatever latest decides to be on the day your pipeline runs.

Rollback support

One thing that trips teams up: a validation can pass, a merge can happen, and then the real deploy to production can still fail — timeouts, org-state drift, row locking, you name it. Salesforce will automatically roll back the org when a deploy fails, but your git branch still contains the merged change that never actually landed.

CairnCI has optional rollback support to handle this. You can configure it to automatically open a PR that reverts the merged change, or to push the revert directly (if your branch allows it). The deploy job still reports failure so the problem stays visible — no silent pretending everything is fine.

Getting started

The repo is at github.com/Fossiltalk/CairnCI and the docs/consumer-setup.md file walks you through the whole setup. The short version for Path A:

  1. Get an SFDX auth URL for each of your orgs
  2. Store it as a secret in a GitHub Environment
  3. Copy the example caller workflows into your .github/workflows/ directory
  4. (Optional) Add a .cairnci/config.json to control behavior in-repo

A minimal validate workflow is literally six lines. That’s it.

This is version 1 — contributions welcome

CairnCI is community-maintained and open to contributions. There’s a lot of room to grow — more governance gates, expanded rollback options, additional runner support, whatever the community finds most useful. If you run into a bug, have a feature idea, or want to contribute, the repo is open and I’m paying attention to it.

The goal is for this to be the kind of tool that teams actually want to use — not a pipeline they cobble together under deadline pressure and then never touch again because nobody understands how it works. Something maintainable. Something that a human has to deal with.

Because at the end of the day, there’s always a human who has to maintain it. 👀

CairnCI is not affiliated with or endorsed by Salesforce, Inc. “Salesforce,” “Salesforce DX,” and “SFDX” are trademarks of Salesforce, Inc.

Creating Dynamic Clock Emojis to Tell Time

Sometimes, you just want the system to feel a little more alive.

We spend so much time staring at record pages, grids, and compact layouts that they can start to feel static. I wanted to add a small UI touch that would reflect the real world—specifically, a clock emoji that actually updates to match the current time.

It started as a fun experiment to see if I could get a Formula Field to output the correct clock face (🕐 vs 🕠) rounded to the nearest 30 minutes. It turns out, you can, but it requires a little bit of math to handle the rounding and the timezone offsets.

Here is how I built it.

The Logic

Instead of writing a massive IF/ELSE statement for every single time slot, I used a math-based approach.

  1. Convert time to an index: I treat the 12-hour clock as 24 distinct “slots” (12 hours x 2 half-hour increments).
  2. Round the minutes: We add a “buffer” of 15 minutes before dividing by 30. This ensures that 1:14 rounds down to 1:00, but 1:15 rounds up to 1:30.
  3. Map the index: A simple CASE statement swaps the calculated number (0-23) for the correct emoji.

The Formula (Eastern Time)

The tricky part is that Salesforce formulas calculate in UTC (GMT). If you are in Eastern Time (like me), TIMENOW() will be 4 or 5 hours ahead of you.

To fix this, we have to subtract the milliseconds equivalent of 5 hours (18000000) from the current time.

Here is the code you can paste into a Text Formula field:

A Note on Daylight Savings

Because Salesforce formulas don’t automatically handle Daylight Saving Time (DST) inside the TIMENOW() function, this formula relies on a hardcoded offset.

  • Standard Time (Winter): Use 18000000 (5 hours)
  • Daylight Time (Summer): Use 14400000 (4 hours)

Twice a year, when you change your microwave clock, just pop into the Object Manager and swap that number. It’s a small price to pay for a system that smiles back at you!

Why do this?

Functionally, does this change how we close deals? Probably not. But user experience is about more than just clicking buttons. Small pieces of Micro UX like this make the org feel personalized and polished.

Give it a try and let me know what you think!