SyncOnAI360

GitHub connector, beta

Keep your Salesforce repository in step with the org.

When a change deploys through SyncOnAI 360, the same metadata can land on a branch in your GitHub repository as a pull request that links back to the proposal and its receipt.

Start freeSee governed deploys

Proposal: Case intake fault handling

Acme Production

Checks passed
  • Validated against the org without changing it
  • No component outside the change is modified
  • Apex tests pass, coverage 81%
  • No freeze window in effect
  • Policy: production requires a second admin

Blast radius

  • 2 Flows read Case.Priority
  • 1 report filters on it
  • Case_Intake_Route assigns from it

Risk: medium

In one paragraph

The SyncOnAI 360 GitHub connector, in beta, records deployed Salesforce changes in a GitHub.com repository. After a proposal deploys, the same metadata is committed to a new branch under your source path and a pull request is opened that links to the proposal and its receipt. It uses a token you scope to one repository.

Commit per change, however many files
1Commit per change, however many files
Repository per token, scoped by you
1Repository per token, scoped by you
Routes into the org through Git
0Routes into the org through Git
Built and tested, early in live use
BetaBuilt and tested, early in live use

01The problem

Why the Salesforce repository drifts from the org

Teams that keep metadata in Git need the repository to match production. Every change made outside the Git flow, from Setup, a builder or an AI tool, makes the repository a little less true.

  1. 01

    Changes outside Git

    Declarative changes deployed directly never reach the repository.

  2. 02

    Reconciling by hand

    Someone retrieves metadata and commits it later, if they remember.

  3. 03

    No link to the decision

    A commit does not say who approved the change or what was asked for.

  4. 04

    Tools that want everything

    Git integrations often ask for broad access to every repository.

02pr

What happens in GitHub when a Salesforce change deploys?

Once a proposal has deployed, the same metadata that went to the org is written to a new branch in your repository as one commit, under your source path, and a pull request is opened against your base branch. The pull request links back to the proposal and its receipt, so a reviewer can see the checks and the approval behind it.

Only changes that reached the org are committed. Pull requests can open automatically after each successful deploy, or be opened by hand from a deployed proposal.

  • One commit per change
  • Linked to the proposal and receipt
  • Automatic or manual

Proposal: Case intake fault handling

Acme Production

Checks passed
  • Validated against the org without changing it
  • No component outside the change is modified
  • Apex tests pass, coverage 81%
  • No freeze window in effect
  • Policy: production requires a second admin

Blast radius

  • 2 Flows read Case.Priority
  • 1 report filters on it
  • Case_Intake_Route assigns from it

Risk: medium

03safe

Can GitHub be used to change the Salesforce org?

No. The pull request is a record and a review surface, not a second route into the org. Every change still reaches the org through a proposal, with named checks, validation against the org and approval for production.

That keeps one governed path to production while the repository stays a faithful history of what was deployed.

  • A record, not a route
  • One governed path stays
  • Repository mirrors what deployed

Proposal: Case intake fault handling

Acme Production

Checks passed
  • Validated against the org without changing it
  • No component outside the change is modified
  • Apex tests pass, coverage 81%
  • No freeze window in effect
  • Policy: production requires a second admin

Blast radius

  • 2 Flows read Case.Priority
  • 1 report filters on it
  • Case_Intake_Route assigns from it

Risk: medium

04connect

How do you connect GitHub to SyncOnAI 360?

Create a fine-grained personal access token in GitHub, scoped by you to exactly one repository, and paste it with the repository name under Integrations, GitHub. Choose the base branch, or leave it to use the repository's default, and the source path, which defaults to force-app/main/default.

The token is stored encrypted, and you can revoke it in GitHub at any time without involving us.

  • Token scoped to one repository
  • Base branch and source path
  • Revoke from GitHub

Claude Desktop

Connected to SyncOnAI 360 · read only

Read only

In the production org, what uses Account.Rating?

  • List orgs3 orgs this token can read
  • Where usedAccount.Rating: 4 components
  • Audit findingsLatest assessment: 37 open findings

Four components use Account.Rating: two Flows, one report and a validation rule. This covers every component this token can see.

3 calls recorded in your workspace activity log

05tidy

How are branches kept tidy?

Every branch the connector creates starts with its own prefix. When you refresh the integration page, pull request states are updated, and branches whose pull requests are merged or closed are deleted.

Only branches this product created and recorded are ever touched. A branch with an open pull request, or one a person made by hand, is left alone.

  • Its own branch prefix
  • Cleanup on refresh
  • Hand-made branches untouched

Proposal: Case intake fault handling

Acme Production

Checks passed
  • Validated against the org without changing it
  • No component outside the change is modified
  • Apex tests pass, coverage 81%
  • No freeze window in effect
  • Policy: production requires a second admin

Blast radius

  • 2 Flows read Case.Priority
  • 1 report filters on it
  • Case_Intake_Route assigns from it

Risk: medium

06limits

What are the limits of the GitHub connector?

It works with GitHub.com only; GitHub Enterprise Server is not supported. Commits and pull requests are authored by the owner of the token. Deploy status is not written back to GitHub as commit statuses, and branch cleanup runs when someone refreshes rather than on a schedule.

The connector is in beta: it is built and tested, and early in live use with real repositories.

  • GitHub.com only
  • Authored by the token owner
  • No status written back
  • In beta

Proposal: Case intake fault handling

Acme Production

Checks passed
  • Validated against the org without changing it
  • No component outside the change is modified
  • Apex tests pass, coverage 81%
  • No freeze window in effect
  • Policy: production requires a second admin

Blast radius

  • 2 Flows read Case.Priority
  • 1 report filters on it
  • Case_Intake_Route assigns from it

Risk: medium

07review

How does a pull request help code review?

The pull request carries the same files the deploy used, written as one commit, so a reviewer reads the change the way they read any other code: file by file, in the team's usual review flow. Its description links to the proposal, with its named checks and blast radius, and to the receipt, with who approved it and when.

Teams that review code in GitHub keep doing so, while admin and AI-built changes reach the org through the governed path.

  • Same files as the deploy
  • Linked to checks and approval
  • Your usual review flow

Proposal: Case intake fault handling

Acme Production

Checks passed
  • Validated against the org without changing it
  • No component outside the change is modified
  • Apex tests pass, coverage 81%
  • No freeze window in effect
  • Policy: production requires a second admin

Blast radius

  • 2 Flows read Case.Priority
  • 1 report filters on it
  • Case_Intake_Route assigns from it

Risk: medium

08How it works

Connecting GitHub

Once per workspace.

  1. 01

    Create a token

    Fine-grained, scoped to one repository.

  2. 02

    Connect

    Repository, base branch and source path.

  3. 03

    Deploy

    Ship a change through a proposal as usual.

  4. 04

    Review

    A pull request with the same files appears.

09Before and after

The Salesforce repository, drifting versus in step

Without

With SyncOnAI 360

Declarative changes never reach Git

Every deployed change can open a pull request

Retrieve and commit later

The same files the deploy used

Commits with no context

Linked to the proposal and receipt

Broad access to every repository

A token scoped to one repository

10Who uses it

Who uses the GitHub connector

Salesforce developersKeep the repository true to production while admins ship declarative changes through SyncOnAI 360.Release managersReview deployed changes in the pull request flow the team already uses.Technical architectsKeep one history of the org in Git, with each change linked to its decision.ConsultanciesLeave a client's repository matching what was delivered, change by change.

11Questions

Frequently asked questions

No. Changes reach the org through proposals. GitHub receives a record of what was deployed.

No. GitHub.com only.

The owner of the token you supplied.

Yes, after each successful deploy, if you turn that on. They can also be opened by hand.

No. The pull request records the change; it is not updated when the org changes again.

Only branches it created, and only when their pull requests are merged or closed, when someone refreshes the integration page.

It is built and tested, and early in live use with real repositories. We would rather say so.

Not today.

Yes. Every plan includes every feature.

Your source path, which defaults to force-app/main/default, so files land where a Salesforce project expects them.

Branches the connector creates always start with its own prefix, so cleanup can never touch a branch a person made.

12Keep exploring

Related

Deploy and ApprovalsChecks, approval, receipts, rollbackDeploy ReceiptsA full record behind every deployCursorYour org beside your code in CursorJiraFindings to Jira issues, status checked backSalesforce developersApex, LWC and real org contextPricingEvery feature on every plan

Start in 5 minutes. No card required.

Connect your Salesforce org. Run your first health scan. Ask your first question. See what you've been missing.

Start free, connect my orgBook a demo with SyncOnAI
  • Anthropic
  • OpenAI