How to Trigger LWC GitHub Actions from Salesforce UI

I've spent a lot of time lately on the seam between Salesforce and our dev tools. One of the cleanest patterns I've found runs GitHub Actions from an LWC, so nobody has to leave the browser tab they are already working in. 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?

We've all done the tab dance. You're working in a sandbox, you finish your changes, and now you have to jump over to GitHub, find the right repo, and manually kick off a workflow. That's context switching at its worst. Wiring GitHub Actions to an LWC puts your CI/CD pipeline inside the CRM, where the work already is.

Admins get something out of this too. I've seen teams where an admin needs to trigger a specific automation or a scratch org build but isn't comfortable poking around in GitHub. This approach lets you build a safe, controlled interface for them. You decide exactly what they can trigger and which 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. A Custom Metadata Type holds the settings: repo name, owner, default branch. An Apex service class makes the HTTP callout to the GitHub API. A small LWC sits on top as the dashboard.

This follows the same principles I've written about for Salesforce API integration. You want the configuration 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. That makes your component reusable: one record for "Deploy to UAT," another for "Run Regression Tests," both running through the same LWC and Apex code.

Building the Apex middleware

The Apex class does the real work. It reads those metadata settings and fires a POST at GitHub's repository dispatch or workflow dispatch endpoint. Here's roughly what that service class looks like.

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();
    }
}

Why check for a 204? That's just how GitHub's API works for dispatches. It doesn't give you a fancy "Job ID" back immediately. It 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. Keep it clean: a couple of input fields prefilled from your metadata, and a button. When the user clicks it, the LWC calls the Apex method, shows a spinner, and raises a toast when the callout comes back.

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 leave the spinner spinning 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.
• Use LightningToastEvent to tell users if the workflow actually started.
• Design your GitHub workflow to accept inputs so you can pass things like the Org Alias directly from Salesforce.

Is it worth the effort? For me, yes. It takes about an hour to set up, and after that nobody hunts for login credentials or navigates GitHub UI menus to run a simple script. The dev process starts to feel like part of the Salesforce platform, which is where I think it belongs. If you run into issues with API limits or callout timeouts, keep the Apex logic lean.