How to Trigger LWC GitHub Actions from Salesforce UI

Posted by Vinay Vernekar 22nd November 2025

I’ve spent a lot of time lately looking at how we can bridge the gap between Salesforce and our dev tools. One of the cleanest patterns I’ve found involves using LWC GitHub Actions to trigger workflows without ever leaving your browser tab. It’s a lifesaver when you want to give your team a “big red button” for deployments or data refreshes.

Why trigger LWC GitHub Actions from the UI?

Look, we’ve all been there. You’re working in a sandbox, you’ve finished your changes, and now you have to jump over to GitHub, find the right repo, and manually kick off a workflow. It’s context switching at its worst. By setting up LWC GitHub Actions, you’re basically bringing the power of your CI/CD pipeline directly into the CRM.

And it isn’t just for developers. I’ve seen teams where admins need to trigger a specific automation or a scratch org build, but they aren’t comfortable poking around in GitHub. This approach lets you build a safe, controlled interface for them. You get to decide exactly what they can trigger and what parameters they can pass.

One thing that trips people up is security. Never, ever hardcode your GitHub Personal Access Token (PAT) in your JavaScript. Always keep that logic on the server side in Apex.

Setting up the LWC GitHub Actions architecture

The setup is pretty straightforward. We use a Custom Metadata Type to store our settings – things like the repo name, owner, and the default branch. Then we use an Apex service class to handle the actual HTTP callout to the GitHub API. Finally, we build a simple LWC to act as our dashboard.

This follows the same principles I’ve discussed before regarding Salesforce API integration. You want your configuration to be metadata-driven so you don’t have to deploy code just to change a repository name or a branch.

1. Get your GitHub credentials ready

You’ll need a Personal Access Token (PAT) with “repo” and “workflow” permissions. If you’re working in a larger org, you might want to look into GitHub Apps or fine-grained tokens instead. Whatever you choose, keep it safe. I usually store these in a protected Custom Metadata field or a Named Credential if the API structure allows for it.

2. The Custom Metadata Type

Create a Custom Metadata Type called Github_Settings__mdt. You’ll want fields for the Owner, Repo, Workflow ID, and the Branch. This makes your component reusable. You can have one record for “Deploy to UAT” and another for “Run Regression Tests,” all using the same LWC and Apex code.

Building the Apex middleware

The Apex class is the workhorse here. It’s going to grab those metadata settings and fire off a POST request to GitHub’s repository dispatch or workflow dispatch endpoint. Here’s a look at how that service class usually looks.

public class GitHubActionService {
    
    @AuraEnabled(cacheable=true)
    public static Map<String, String> getDefaultGitHubSettings(String githubFlow) {
        Map<String, String> settings = new Map<String, String>();
        Github_Settings__mdt config = Github_Settings__mdt.getInstance(githubFlow);
        if (config != null) {
            settings.put('githubOwner', config.Github_Owner__c);
            settings.put('githubRepo', config.Github_Repo__c);
            settings.put('githubWorkflow', config.Github_Workflow__c);
            settings.put('githubBranch', config.Github_Branch__c);
            settings.put('githubPAT', config.Github_PAT__c);
        }
        return settings;
    }
    
    @AuraEnabled
    public static String triggerWorkflow(String githubOwner, String githubRepo, String githubWorkflow, String githubBranch, String githubPat, String orgAlias) {
        Http http = new Http();
        HttpRequest request = new HttpRequest();
        request.setEndpoint('https://api.github.com/repos/' + githubOwner + '/' + githubRepo + '/actions/workflows/' + githubWorkflow + '/dispatches');
        request.setMethod('POST');
        request.setHeader('Authorization', 'Bearer ' + githubPat);
        request.setHeader('Accept', 'application/vnd.github+json');
        
        Map<String, Object> payload = new Map<String, Object>();
        payload.put('ref', githubBranch);
        payload.put('inputs', new Map<String, String>{'ORG_ALIAS' => orgAlias});
        
        request.setBody(JSON.serialize(payload));
        HttpResponse response = http.send(request);
        return (response.getStatusCode() == 204) ? 'SUCCESS' : 'ERROR: ' + response.getBody();
    }
}

But wait, why return a 204? That’s just how GitHub’s API works for dispatches. It doesn’t give you a fancy “Job ID” back immediately. It just tells you, “Got it, I’ll start working on it.” If you’re interested in more automated GitHub tasks, you might want to check out how to prevent org expiry with GitHub Actions as well.

The LWC Frontend

Now for the LWC. You want something clean. A couple of input fields (pre-filled from your metadata) and a button. When the user clicks that button, the LWC calls the Apex method, shows a spinner, and then gives a toast message when it’s done. This is the heart of the LWC GitHub Actions experience.

In my experience, the most overlooked part here is error handling. If the GitHub API is down or the PAT has expired, your LWC needs to tell the user exactly what happened. Don’t just let the spinner spin forever. That’s a quick way to lose the trust of your users.

Key Takeaways for LWC GitHub Actions

  • Metadata is King: Don’t hardcode repo URLs or branches. Use Custom Metadata so you can update settings without a deployment.
  • Security First: Keep your GitHub tokens in Apex. Never expose them to the client-side LWC.
  • User Feedback: Use LightningToastEvent to tell users if the workflow actually started.
  • Flexibility: Design your GitHub workflow to accept inputs so you can pass things like the Org Alias directly from Salesforce.

So, is this worth the effort? Absolutely. It takes about an hour to set up, but the time it saves your team in the long run is massive. No more hunting for login credentials or navigating complex GitHub UI menus just to run a simple script. You’re making the dev process feel like a part of the Salesforce platform, which is exactly where it should be.

Give this pattern a try in your next project. It’s a small change that makes a huge difference in how your team interacts with your CI/CD pipeline. If you run into issues with the API limits or callout timeouts, just remember to keep your logic lean and mean.

Tags: