Looking for the previous version? View v2024.06 documentation →
Version Controls
Connect Data Trust to Git for scenario versioning, comparison, and rollback.
Overview
The Version Controls section integrates Data Trust with external source control systems such as GitHub. Once configured, users can commit FDR scenario definitions to a Git repository directly from Data Trust, view full version history, compare differences between versions, and restore an earlier version when needed. This provides a complete audit trail and enables collaborative version management of reconciliation logic.
Prerequisites
- You are logged in to Data Trust with an Admin Pro-User role.
- Admin Console access has been granted by your system administrator.
- A Git repository and access credentials (personal access token) are available.
Navigating to Version Controls
Path: Data Trust › Admin Console › System Preferences › Version Controls
Figure 1: System Preferences navigation option
Open Admin Console and navigate to System Preferences to find the Version Controls configuration tile for setting up Git integration. Version Controls is accessible only to users with an Admin Pro-User role and requires a Git repository and personal access token to be prepared in advance. This configuration is typically performed once during platform setup and then maintained whenever repository credentials change.
Figure 2: Version Control tab
The Version Control tab within System Preferences lists all currently configured Git instances and provides options to add new repository connections. Each row in the list shows the Git instance name, repository URL, and the branch it targets, along with Edit and Delete action icons. Data Trust supports connecting to GitHub, Azure DevOps Git repositories, and other Git-compatible services using personal access tokens for authentication.
Configuring a Git Instance
- On the Version Control page, click Add to configure a new Git instance.
- Provide all required details: instance name, repository URL, branch, and personal access token.
- Click Test Connection to verify the credentials and repository access.
- Click Save to complete the Git instance configuration.
Figure 3: Version Control page
The Version Control page shows all existing Git instance configurations with their connection status and repository details. Click the Add button to open the configuration form for connecting a new Git repository to Data Trust. If no Git instances have been configured yet, this page will be empty and the Add button is the only available action.
Figure 4: Provide all Git instance details
Enter the Git instance name (a friendly label for this connection), the full repository clone URL, the target branch name, and the personal access token (PAT) in the configuration form. The instance name is how this Git connection will be identified in the FDR scenario Version Control interface. Ensure the PAT has at least repository read and write permissions so that Data Trust can push scenario version commits to the target branch.
Figure 5: Test Connection button
The Test Connection button validates the provided PAT and repository URL against the specified Git service before saving the configuration. Clicking this button is mandatory before you can save — Data Trust will not allow saving a Git instance configuration that has not passed the connection test. If the test fails, verify that the repository URL is correct, the branch name exists, and the PAT has not expired or been revoked.
Figure 6: Test Connection successful message
A success message confirms that Data Trust can successfully reach and authenticate to the Git repository using the provided credentials. After seeing this confirmation, click Save to persist the Git instance configuration. If you update the PAT or repository URL in the future, always re-run the Test Connection to verify the new details before saving.
Figure 7: GitHub instance added successfully
A success confirmation is displayed after saving, and the new Git instance appears in the Version Control list ready for use in version-managed FDR scenarios. Users with access to FDR scenarios can now select this Git instance when committing a scenario version from Scenario Studio. The Git instance name you provided will appear in the version control dropdown within the FDR scenario editor.
Committing a Version from an FDR Scenario
- Navigate to the FDR scenario you want to version and click the Version Control button.
- Enter a descriptive commit message in the dialog that appears.
Figure 8: FDR option in scenario navigation
Navigate to the FDR scenario you want to version from Scenario Studio and open its editing view to access the Version Control toolbar button. Version Control is available for FDR scenarios that have been associated with a configured Git instance in System Preferences. Make all intended changes to the scenario before committing a new version — each commit represents a snapshot of the complete scenario definition at that point in time.
Figure 9: Click on Version Control button
Clicking the Version Control button in the FDR scenario toolbar initiates the commit workflow for the current state of the scenario definition. A dialog will appear prompting you to enter a descriptive commit message before the version is pushed to the Git repository. Ensure your changes are complete and saved before clicking this button, as the commit will capture the scenario exactly as it stands at this moment.
Figure 10: Enter commit message dialog
The commit message dialog requires you to provide a meaningful description of the changes made to the scenario in this version. A good commit message includes the reason for the change and a brief summary — for example, 'Added new source column mapping for Q3 reporting' or 'Fixed calculation in reconciliation rule 5.' Clear commit messages make it significantly easier for your team to identify the right version to restore or compare in the future.
Figure 11: Click on Version History button
After committing the scenario version, click the Version History button in the toolbar to view the full list of all saved versions for this scenario. Each entry in the version history shows the commit message, author name, and timestamp for easy identification. From the Version History panel, you can compare two versions or restore a previous one if the current state needs to be rolled back.
Figure 12: Version saved confirmation
A confirmation message indicates that the scenario definition has been successfully committed and pushed to the configured Git repository. The new version entry is immediately visible in the Version History list for this scenario. Navigate to your Git repository externally (for example, in GitHub) to verify the commit appears in the target branch with the message you provided.
Viewing and Comparing Versions
- After making further changes, commit another version to create a comparison baseline.
- Select two versions from the history list and click Version Compare.
Figure 13: Adding an Email Widget and saving another version
By adding new components to the scenario — such as an Email Widget — and committing again, you build a version history that captures the evolution of the scenario over time. Each commit creates a new entry in the version list with a distinct timestamp and commit message, making it easy to trace when specific changes were introduced. Maintaining a series of well-described commits allows your team to collaborate on scenario development with full transparency and rollback capability.
Figure 14: Version History button after second commit
After the second commit, the Version History button shows multiple version entries — click it to open the history panel and view all available versions for comparison or restoration. Select two specific versions from the list by ticking their checkboxes before using the Version Compare function. The most recent commit is shown at the top of the list; scroll down to see older versions if the history spans many commits.
Figure 15: Select two versions and click Version Compare
Tick the checkboxes next to two versions in the Version History list and then click Version Compare to open a side-by-side diff view of the two scenario definitions. Selecting more than two versions will disable the Compare button — ensure exactly two are selected before clicking. The comparison highlights all differences between the two versions, making it easy to identify exactly what changed between commits.
Figure 16: Compare Versions tab
The Compare Versions tab displays a structured diff view that highlights additions (shown in green), removals (shown in red), and modifications between the two selected scenario versions. Use this view to review changes before deciding whether to restore an older version or accept the current state. The comparison is read-only and cannot be used to merge individual changes — if you need to roll back, use the Restore Version function.
Restoring a Previous Version
- In the Version History, select the version to restore and click Restore Version.
Figure 17: Select version and click Restore Version button
Select the desired historical version from the Version History list and click the Restore Version button to roll back the scenario definition to that saved state. A confirmation dialog will appear before the restore is applied, giving you a final opportunity to verify you have selected the correct version. The restore operation replaces the current scenario definition with the selected historical version and saves it as the active configuration.
Figure 18: Version restored confirmation
A success message confirms the scenario has been restored to the selected version and the restored state is also automatically committed to the Git repository as a new version entry. This automatic commit preserves the audit trail by recording the restore action in the version history alongside a system-generated commit message. After restoration, verify the scenario runs correctly before notifying users that the rollback is complete.