Source Control in ServiceNow Studio - Walkthrough (text-only)

Earl Duque
Administrator
Administrator
4 weeks ago

With the ServiceNow Zurich release, Source Control has finally been added to ServiceNow Studio.

 

ServiceNow Studio is the new, unified developer environment on the Now Platform, designed to streamline the development experience for ServiceNow developers.

 

When ServiceNow Studio was initially released, one of the features that was missing was the integration with Source Controlled repositories.

 

Now that the feature has made its way into the ServiceNow Studio, I wanted to make this comprehensive guide on how to utilize it.

 

Version with screenshots

 

I made this version because I know some people absolutely cannot stand having so many images in a walkthrough. But if you prefer seeing screenshots for almost every step of this walkthrough, you can find that version at the following link! 

https://www.servicenow.com/community/developer-advocate-blog/source-control-in-servicenow-studio-com... 

 

Overview

  1. Quick course on source control and ServiceNow
  2. Create a repository on a remote git service like GitHub
  3. Create a credential in ServiceNow
  4. Connect your scoped app in ServiceNow to the Git Repository
    1. Connecting an existing scoped app
    2. Creating a new scoped app to connect
    3. Updating your Git repository’s main branch
  5. Commit changes to your remote repository
  6. Installing an app on a different instance from source control
  7. Pull changes from your remote repository
  8. Handling stashes
  9. Creating branches in your app
  10. Creating tags in your app
  11. Additional warnings

 

Quick course on source control and ServiceNow

 

This isn’t a full lesson as there’s so much to source control, but here’s the important stuff to know as a ServiceNow developer. Source control is about tracking changes to your code over time, collaborating safely with others, and being able to roll back if things go wrong.

 

A repository (repo) is just a project folder managed by Git that records every change you make. Think of it as a living history of your app. You push commits into it when you want to lock in a version of your work, and you can pull those commits back into any other instance or environment that’s linked.

 

This is different from update sets in ServiceNow. Update sets capture changes in your instance and move them between environments, but they’re one-directional, and hard to track when multiple developers are involved. With source control, your app lives in a Git repo (like GitHub), so you get a central source of truth, proper versioning, and a smoother way to collaborate across instances and teams.

 

Creating a Git repository

 

Source control and Git is technically an “integration” in ServiceNow Studio since ServiceNow doesn’t actually do any Git processes, so we integrate with existing Git services. For this walkthrough we will be using GitHub.

  1. Go to Github.com and create an account if you don’t already have one
  2. Go to your profile and click on the “Repositories” tab and then click “New”
  3. Set up your repository:
    1. Repository name: usually the name of your app
    2. Choose visibility:
      1.       Public, if you’re okay with everyone to be able to see it
      2.       Private if you want yourself to be the only person to access it, you can always grant individual access later too
    3. Add README: set this to “On”. This will create a “readme.md” file in your repository. Readme files are documentation files that explain what a project is, how to install or use it, and any other essential details for developers or users. It’s always a good idea to eventually add documentation to your repository but even if you don’t utilize the readme file, it doesn’t hurt to have.
    4. You can also add a description if you want (optional)
    5. Press “Create repository” when done.
  4. You now have a new repository for you to save your ServiceNow app into!
    Note this URL, we’ll need it for later. Mine looks like https://github.com/earlduque/Sierra-Charlie

 

Create a credential in ServiceNow

 

To connect ServiceNow to a remote Git service like GitHub we need to configure a secure credential between the two systems. “This credential says I have permission to manipulate the GitHub repository.” This step will require you to do some configuration in both GitHub and in your ServiceNow instance

 

In GitHub

 

We need to create a token in GitHub (this token is what says “I have permission”) that we will later save in ServiceNow.

  1. Click on your avatar on the top right of your GitHub interface
  2. On the menu that opens, click on “Settings”
  3. In settings, in the menu on the left side, scroll all the way down and click on  “Developer settings”
  4. Click on “Personal access tokens” to expand its menu and then click on “Fine-grained tokens”
  5. Click on “Generate new token”
  6. Give your token a name. I like to give it the same name as the instance I am going to use it on. It’s best practice to be as granular as possible when creating tokens (as in, more granular than per instance, like per scoped app), because then you will be able to revoke or expire specific tokens as needed.
  7. Pick an expiration date
    Note that it is best practice that tokens have expiration dates and then you manage a process to make sure tokens are regenerated and swapped out before their expiration dates.
    Besides relative days (30 days, 60 days, etc.) you can also set a specific date for expiration, or you can set ”no expiration”.
    Warning! Because a GitHub token is basically a key to your account or repository, having it last forever is risky. If a token with no expiration date gets exposed, say it ends up in logs, a public repo, or on a compromised machine, it gives an attacker indefinite access.
  8. Decide what repositories your token should have access to.
    Again, it’s best practice for security reasons to be as granular as possible. As in, only select specific repositories.
  9. Under “Permissions”, click on “Add permissions” and then “Contents”.
    This will add both the ”Contents” permission (needed for clone, pull, push) and the ”Metadata” permission (this just lets the token see the repo exists)
  10. We need to be able to write to the contents, not just read them, so change “Read-only” for contents to “Read and write”
  11. Time to generate the token!
    Get ready! Note that after this step, once the token is generated, it will only be visible once and never again for security purposes. Be prepared to save it somewhere secure.
    Click “Generate token”
    It will show one more screen, summarizing your new token that is about to be created, click ”Generate token” one more time.
  12. You will be brought back to your “Fine-grained personal access tokens” page. The token you have just made will appear here now and only now. Once you navigate away from the page, it will never be shown to you again for security purposes. Press the Copy button now and save it somewhere secure. It is your responsibility to keep this token secure.
    (I know I’m displaying a token here, but I’ve already expired this token before this blog has been posted).

 

Saving your token in your ServiceNow instance

 

Now that you have your GitHub token, we need to save it in ServiceNow as a credential. ServiceNow Studio Source Control will use this credential (that has your token) to prove that it has access to your GitHub repository.

  1. Login to your instance
  2. Navigate to “Credentials” in the “Connections & Credentials” menu
  3. Once you are at the Credentials table, click “New” to start making a new credential record
  4. On the following screen it will ask you “What type of Credentials would you like to create?” Select “Basic Auth Credentials”.
    Why “Basic Auth”? Because the GitHub token acts as a secure stand-in for your GitHub password in a simple “username + password” combo. That also means, that no, you cannot simply use your GitHub account password for this credential, it has to be a personal access token.
  5. Configure your credential record:
    1. Name it so that you clearly know which PAT it reflects
    2. User name is the exact user name of your GitHub account (for me, my GitHub profile is at github.com/earlduque, so my GitHub username is earlduque)
    3. Password is the token that you noted earlier
  6. Click Submit

 

Connecting your repository to your scoped app

 

It’s finally time to link your scoped app to your Git repository!

  1. In your ServiceNow instance, navigate to “ServiceNow Studio” under the “System Applications” menu.
    Note that there is a plain “Studio” option, this option is the legacy Studio and not the tool we are using today.
  2. ServiceNow Studio will launch a new tab in your browser.
    If this is your first time in ServiceNow Studio, I would highly recommend that you read elsewhere about how this interface is laid out. For this walkthrough, we’ll jump right into configuring it for source control.

 

Linking an existing app to your repo

 

If you have an existing ServiceNow Scoped Application that you want to link to your Git repository, follow the following steps. If you are creating a brand-new scoped application, skip to the following section.

  1. Ensure you are in the “Apps” tab in ServiceNow Studio
  2. Select your app from the Apps list.
  3. You will be brought to the file view of your app, click on “App details”
  4. A new Studio tab will open showing your app details. In the top-right menu, you’ll see the new “Source control” menu, click on that to show all of your source control options. For now, since we’re still configuring source control, you will only see the “Link to source control” option, but more options will appear later. Click on “Link to source control”
  5. Configure the connection:
    1. URL will be the URL of your GitHub repository that you noted earlier.
    2. Branch will default to “sn_instances/yourinstance”, I recommend that you leave this alone as it helps show where Git changes are being generated from. Later, we will show you how to change your git repository’s default branch to this branch if this will be your production branch.
      Otherwise, you can set this to “main” if you want to match the existing branch in your GitHub repository (GitHub by default will create you a “main” branch when you create a repo).
    3. For Credential, select the credential record that you created earlier.
    4. Click on “Link to source control”
  6. ServiceNow will now go to GitHub and create a file and folder structure to host your ServiceNow app! Click “Close” upon completion.
  7. You can verify the link was successful by clicking on the “Source control” menu dropdown again, you should see more options now
    Additionally, if you go to your GitHub repository, the new branch should now be an option for you to select

 

Your app is now committed to a source control repository on GitHub! You can now proceed to do development as normal for your app in ServiceNow!

 

 

If you are starting fresh and are ready to create a new app in ServiceNow Studio, follow these next steps. If you have already connected an existing app to your repo, you can skip this section.

  1. Ensure you are in the “Apps” tab in ServiceNow Studio
  2. On the top-right of ServiceNow Studio, click on the “Create” menu, and then click on “App”
  3. Begin configuring your new app. For brevity, I will be doing the minimum required to start a new app. Always feel free to do more configurations if you need to.
    1. Name your app
      Note: this will also generate the app scope name which will prepend custom table names.
    2. Leave it as a “Scoped” app
    3. Click “Continue”
  4. On the next screen, you can configure what roles should be created for this new app. You can also just click “Continue” to move on with the default admin and user roles.
  5. It will start creating the app structure of your new ServiceNow app
  6. Upon completion you will see “Great! Let's add more to your app!”
    If you want to build more of your app first, you can start creating files. To resume integrating with source control, come back to this guide’s “onnecting an existing scoped app” section.
    Click “View app details” to get to the next step for source control integration.
  7. A new Studio tab will open showing your app details. In the top-right menu, you’ll see the new “Source control” menu, click on that to show all of your source control options. For now, since we’re still configuring source control, you will only see the “Link to source control” option, but more options will appear later. Click on “Link to source control”
  8. Configure the connection:
    1. URL will be the URL of your GitHub repository that you noted earlier.
    2. Branch will default to “sn_instances/yourinstance”, I recommend that you leave this alone as it helps show where Git changes are being generated from. Later, we will show you how to change your git repository’s default branch to this branch if this will be your production branch.
      Otherwise, you can set this to “main” if you want to match the existing branch in your GitHub repository (GitHub by default will create you a “main” branch when you create a repo).
    3. For Credential, select the credential record that you created earlier.
    4. Click on “Link to source control”
  9. ServiceNow will now go to GitHub and create a file and folder structure to host your ServiceNow app! Click “Close” upon completion.
  10. You can verify the link was successful by clicking on the “Source control” menu dropdown again, you should see more options now
    Additionally, if you go to your GitHub repository, the new branch should now be an option for you to select

 

Your app is now committed to a source control repository on GitHub! You can now proceed to do development as normal for your app in ServiceNow!

 

Updating your Git repository’s main branch

 

When connecting your ServiceNow app to a repo, if you chose to default the initial branch name to something like “sn_instances/yourinstance” instead of “main”, then we should do one more configuration on the GitHub side.

  1. Login to GitHub and go to your repository
  2. Click on “Settings”
  3. In the “General” settings area of the Settings menu, under “Default Branch”, click on the “Switch to another branch” button
  4. On the screen that appears, click on the branch dropdown menu (should say “Main”), and then select your branch from ServiceNow
  5. Click “Update”
  6. A warning will appear, click “I Understand, update the default branch”

 

And we’re good to go! Now the branch that was created when you configured source control is the “main” branch that all future work should derive from and update to.

 

Commit changes to your remote repository

 

When you make changes to your app in ServiceNow, they still create update files (for the sake of update sets and the like), but they never automatically affect how they are saved in your Git repository.

 

Think of commits as snapshots of your development work. When you’ve reached a point where the changes in your app feel solid enough to preserve (maybe you fixed a bug, added a new feature, or got things into a stable state), you make a commit. That commit locks in the exact state of your code at that moment, giving you a clear history to look back on and the ability to move forward or back if needed.

 

So, you’ve made a bunch of changes to your app and now you need to sync them to your GitHub repository, let’s walk through that process now.

  1. Go back to your app’s “App details” page in ServiceNow Studio
  2. Open the “Source Control” menu and click “Commit changes”
  3. Select all the files changes that you want to commit to the repository. Or select all files by clicking on the top-left checkbox of the list.
    Note: when I say “file changes” I mean any kind of change: created files, updated files, and even deleted files.
    Click “Continue” when you’ve made your selection
  4. On the next screen, review your file selection and create a commit message that exactly describes what this commit will change.
    Click “Commit files” when you’re ready.
  5. Upon completion you will see a success message
  6. Click “Close” to complete the process

 

Congrats! You’ve synced your ServiceNow app to your GitHub repository by committing changes that have happened since your last commit.

 

Installing an app from source control onto a different instance

 

So, you want this app on a different instance now, or a collaborator wants to work on your app on their own instance. The process is very simple in ServiceNow Studio:

  1. Login to an instance that does not have your ServiceNow app installed
  2. In your ServiceNow instance, navigate to “ServiceNow Studio” under the “System Applications” menu.
    Note that there is a plain “Studio” option, this option is the legacy Studio and not the tool we are using today.
  3. ServiceNow Studio will launch a new tab in your browser.
    If this is your first time in ServiceNow Studio, I would highly recommend that you read elsewhere about how this interface is laid out.
  4. On the ServiceNow Studio Home page, on the top-right corner, click on the “Create” menu and select “Import app”
  5. Configure the app for import:
    1. URL will be the GitHub repository URL that you are trying to install
    2. Branch: this must match the name of an existing branch in the repository. As in, you are not creating a branch in this process, you are importing an existing branch. This might not be the value that the import tool defaulted to. If you are unsure of the main branch name, visit the repository URL and the name of the branch appears near the top-left.
    3. Credential: select the credential record that contains the token that has access to this repository (see earlier in this walkthrough on how to make a a token and credential if you haven’t already done so)
    4. Click “Import app” when ready
  6. Note: if it says you don’t have read/write access to this repository, make sure the token you are using has access to that repo, you can go back into your GitHub Personal Access Tokens settings section to verify.
  7. Upon completion of importing, a success message should appear
  8. Click “Open application” to be brought to your newly imported applications App Details page
  9. Note: when you newly import an app via this method, it won’t immediately appear in the apps list in ServiceNow Studio on the left. Simply hit the refresh button to make it appear

 

That’s all! The app is now imported and ready for you to use or update.

 

Pull changes from your remote repository

 

So, someone on a different instance made changes to the app, commited those changes to the repository, and now you want to import those changes to your instance.

 

That’s what we call “pulling” from the repository. Another way to think of “committing” changes is that your “pushing” changes into the repository, that’s why we call it pulling.

  1. Go to your app’s “App Details” page in ServiceNow Studio.
  2. Click on the “Source control” menu and click on “Pull from repository”
  3. Wait! Does the next screen say “There are no unstashed files”?
    1. If yes, good! You’re good to continue and click “Pull from repository” again
    2. If no, there are indeed “unstashed files”, then you’ll need to review the section below “Handling stashes” first, then come back here when that’s done.
  4. Source control will now check to see what is different between the app in your instance and the app in the repository and attempt to make your app look like what is in the repository by “pulling” those differences into your instance. You should see a success message when this is done.

    If there is an error, there are too many different paths of what we would need to do to determine a fix, so leave a comment for your situation and we’ll update this article with known problems as they are found and fixed.
  5. Click “Close” and you’re done!

 

Your app should now reflect what is stored in the repository (in your current branch’s latest commit). ServiceNow Studio will even automatically refresh your app’s file menu so that it’s up to date with any new changes.

 

Handling stashes

 

You attempted to pull in changes from the repository and were told you have unstashed changes? No problem! This happens to me pretty often.

 

What are unstashed changes? Basically, that means there are changes to your instance that have yet to be committed. And if “pulling” from the repository means that source control is going to make the app in your instance look like the app in the repository, you need to decide what to do with those uncommitted changes:

  • You could commit your changes first (see the “commit your changes” section of this walkthrough)
  • You can discard these uncommitted changes so that your app perfectly matches the repository that you are pulling from
  • You can “stash” these uncommitted changes so that once you’re done pulling from the repository, you can reapply them.

 

When prompted with “unstashed changes” you’ll see the latter two options:

 

Discard your local changes

 

To Discard the changes, simply select “Discard local changes” and click “Pull from repository”. Note the warning that says that this cannot be undone and the listed file changes cannot be recovered.

 

Note: it’s important to acknowledge that when you’ve pulled from a repository after selecting “Stash local changes”, applying the “stashed changes” is actually optional. Factor this in if you are choosing “Discard”. It doesn’t hurt to stash and just leave it as a stash.

 

Stashing your changes

 

To stash changes to reapply later, select “Stash local changes” give it a description (for example: “these files apply to this instance only”), and click on “Pull from repository”.

 

Source control pulls the changes from the repository into your instance. You should see a success message when it’s done.

 

Press “Close” to return to your app as normal.

 

Applying your stash

 

This is different than how legacy studio handled pulling after stashing!

 

If you want to apply the changes you’ve stashed away:

  1. Go back to your app’s “App details” page and click on the “Source control” menu and select “Manage stashes”
  2. The “Manage stashes” screen will appear with all the stashes available for this app for this instance
  3. Locate the stash you want to apply and click “Apply”
  4. A stash preview will be generated for you to review, but if the stash is completely safe, it will automatically apply!

 

All done!

 

Creating branches in your app

 

A branch is like a parallel line of development that lets you experiment or work on a feature without disturbing your main app code. In ServiceNow development, you might create a branch when you want to build a new flow or integration, but you’re not ready to risk breaking what’s already working in production.

 

For example, if you’re adding a new flow to your app, you can create a new branch to build on and test that change, then merge it back into your default branch once you’re confident it works.

 

You can create branches quickly in GitHub, but to do it in ServiceNow Studio:

  1. Go to your app’s “App details” page in ServiceNow Studio
  2. Open the “Source Control” menu and click “Create branch”
  3. Enter a name for your new branch. A good practice is to keep it descriptive, like “feature/new-approval-flow" or ”bugfix/broken-business-rule"
    Note: branch names cannot contain spaces or certain special characters besides / and -. Basically, stick to lowercase letters, numbers, and dashes, and prefix the name with things like feature/, bugfix/, hotfix/, release/, etc.
    Click “Create branch” when ready
  4. You will see a success screen when done. You can click “Close” to return to your app
  5. Source control will go to your GitHub repository and create the new branch, and it will automatically switch you to your new branch.
    Note: when you click on your “Source Control” menu at this point, it’ll look like you are still on your previous branch, simply refresh your app details page and it will update to show you the correct branch.

 

Switching branches

 

To switch to the new branch, on your App Details page, click on the “Source control” menu again and select “Switch branch”

 

At this point, you can select which branch you want to go to. Switching branches is essentially the same as pulling that entire branch so if you have unstashed changes, you will need to act on them as normal before proceeding (see the above section about stashes).

 

Creating tags in your app

 

A tag is a snapshot marker that identifies a specific point in your app’s history. Think of it as a label you can put on a commit so you can easily come back to that exact version later.

 

Tags are what we call immutable, you can’t change what a tag points to, which is why they’re reliable for marking releases.

 

In ServiceNow, a good use case is tagging a commit right before you push your app to a test or production instance. If something goes wrong after release, you can quickly pull the tag to roll back or compare the state of your app at that exact deployment point.

 

To create a tag via ServiceNow Studio:

  1. Go to your app’s “App details” page in ServiceNow Studio
  2. Open the “Source Control” menu and click “Create tag”
  3. Enter a name for the tag. Many teams use semantic versioning here, such as “v1.0.0” or “release-2025-08-19"
    Click “Create tag” when ready
  4. That’s really it! Upon success, you can click “Close” to return to your app

 

You can see all your tags in your GitHub repository’s “Tags” section

 

Additional warnings

 

I’ve tried to include the major gotchas and edge cases in the walkthrough where they make the most sense, but there will always be new ones. As more issues come up, I’ll either add them directly into the relevant section or drop them here if they don’t fit anywhere else.

 

A few things to keep in mind:

  • Case sensitivity
    • Git is case-sensitive, but ServiceNow table and file names often aren’t. Be careful when renaming files or scopes, as it can cause conflicts that don’t show up until you push or pull.
  • Binary files
    • Git doesn’t handle large binary files well, so try not to commit attachments or exports directly into your repo. Stick to code and configuration.
  • Force pushes (via the Git side)
    • Avoid them. If you rewrite history on your repo, your ServiceNow instance may no longer line up with what Git thinks is current.
  • Long-lived branches
    • The longer a branch lives without merging, the harder it is to pull changes cleanly later. Commit and merge often.
  • Credential rotation
    • If your GitHub token expires (and it should, for security), you’ll suddenly lose the ability to push or pull. Keep a process for rotating tokens.

 

Thank you!

 

I hope this helps you in your ServiceNow Studio and source control journey. Please let me know if you have any questions or if you have helpful information that I should include in this blog post for future readers.

 

Earl Duque
Sr. Developer Advocate, ServiceNow

  • 1,742 Views
1 Comment
Popular Blog Posts