Changing a data model can affect more than one part of an application. A developer might add a property to an Ontology object, update a function that reads that property, and change a Workshop module that displays the result. If these changes are tested separately against the live environment, a function may fail simply because the corresponding Ontology change has not been released yet.
Palantir Foundry's Global Branching helps developers test these related changes together. As of October 13, 2026, Global Branching is generally available for TypeScript v2 and Python functions. Developers can work with changes to Ontology resources on a branch, preview function behavior, publish a branch-specific function version, and test it in downstream applications before merging the work into the main environment.
This update matters for teams building applications around Foundry's Ontology. They can now develop the function and the data model it depends on in the same branch instead of coordinating every change through separate releases.
What Is Global Branching in Palantir Foundry?
Global Branching is a development workflow that lets teams make and test related changes across supported Foundry resources on one branch.
It is similar in purpose to using a Git feature branch, but it extends beyond source code. A global branch can include changes to supported Ontology resources, functions, Workshop modules, and other platform components.
Consider an application that tracks customer orders. The team wants to add a riskScore property to its Order Ontology object and create a function that calculates a risk category for each order.
Without a shared branch, the team may need to coordinate the schema change, function deployment, and application update carefully. If the function expects riskScore before the property exists in the environment it uses, testing becomes difficult.
With Global Branching, the developer can make the supported Ontology change and develop the function against that branched version. The work can be tested before the changes reach the main environment.
The important point is that a branch provides an isolated development context. It does not automatically make every resource in Foundry branchable, and the exact workflow depends on the resource type.
What Has Changed for TypeScript v2 and Python Functions?
Global Branching already supported several Foundry resource types and earlier function workflows. The October 2026 update extends general availability to TypeScript v2 and Python functions.
The new support includes:
- Adding a TypeScript v2 or Python functions repository to a global branch.
- Developing functions that depend on new or modified Ontology resources on that branch.
- Previewing function behavior in VS Code Workspaces or Code Repositories.
- Publishing branch-specific function versions.
- Testing those versions in supported downstream resources, including Workshop modules, AIP Logic, and function-backed actions.
For example, a developer can change an Ontology object, write a function that uses the new property, and test the function before proposing the changes for merging.
This is useful when a feature involves several related resources. The developer can validate the changes as a unit rather than waiting for each resource to be released independently.
How the Branching Workflow Works
1. Prepare the functions repository
Before developing TypeScript v2 or Python functions on a global branch, the repository must meet the documented requirements.
| Function type | Minimum parent template version | Additional requirement |
|---|
| TypeScript v2 | 0.1299.0 or later | Enable a local Ontology SDK |
| Python | 0.724.0 or later | Enable a local Ontology SDK |
These requirements matter because the function needs access to the Ontology definitions associated with the branch. Check the repository's current template version before starting the migration.
A local Ontology SDK provides the generated types and interfaces used by the function repository. Without the required setup, a repository may be able to reference an existing function version but cannot develop function code against branched schemas.
2. Create or check out a global branch
Create a branch from the main environment and add the functions repository to it. Work on the branch while making the related Ontology and function changes.
For example, the planned changes might include:
- Adding
riskScore to an Order object type. - Updating the function that calculates an order's risk category.
- Changing a Workshop module to display the new category.
The branch keeps these changes together for development and testing.
3. Update the function code
Suppose the application needs to classify orders based on their risk scores. The following TypeScript example shows the business logic that could be used in such a function.
type RiskCategory = "LOW" | "MEDIUM" | "HIGH";
function getRiskCategory(riskScore: number): RiskCategory {
if (riskScore < 0 || riskScore > 100) {
throw new Error("Risk score must be between 0 and 100.");
}
if (riskScore >= 70) {
return "HIGH";
}
if (riskScore >= 40) {
return "MEDIUM";
}
return "LOW";
}
This example illustrates the business logic, not the complete Foundry function registration or Ontology SDK imports. In a real repository, the function must use the types and registration pattern required by its TypeScript v2 or Python template.
The example also shows why testing the function matters. If the team changes the risk-score property or its allowed range, it can check whether the function still behaves as expected before releasing the change.
4. Preview and publish the function on the branch
Use the supported development tools to preview the function against the branched resources. When the function is ready, publish it with a version target that represents the stable version expected to be published to main when the branch merges.
During branch development, the function is published as an unstable preview version. Once published successfully, it can be consumed on that branch by supported downstream resources.
The function version is marked with the Branched pre-release tag. It remains isolated from other branches, including main.
This allows the team to test the new function without making it the stable version used by production resources.
Testing Functions in Downstream Applications
A function can compile successfully and still fail when an application uses it. It may receive unexpected values, depend on a missing property, or return a result that the consuming module does not handle correctly.
Global Branching lets developers test the published branch version in supported downstream resources.
For example, a Workshop module can consume the branch-specific function and display the risk category for an order. A function-backed action can also use the branch version where supported.
This gives developers a chance to check the full path from the Ontology object to the function result and then to the application that displays or uses that result.
The process is more useful than checking the function in isolation because it can reveal problems caused by mismatched resource versions.
One limitation is important: branched versions of query functions cannot currently be used as dependencies in TypeScript v1, TypeScript v2, or Python function repositories. Check the supported dependency types before designing a workflow around branch-specific query functions.
What Happens When the Branch Is Merged?
Merging a global branch publishes its modified functions to main using the stable version target selected during development.
Resources that used the branch-specific function version automatically start using the new stable version published to main as part of the merge.
The platform does not merge every function version created on the branch. It merges the selected version target. Other branch-published versions do not appear in main after the merge.
This distinction matters when a team publishes several experimental versions during testing. Only the intended release target should be used for the final merge.
What if the main function changes while you are working?
A branch does not automatically receive newer function versions published to main. This prevents changes in the main environment from unexpectedly disrupting work in progress.
If a newer version becomes available, Foundry provides notifications through function version selectors and Ontology Manager. Developers can rebase their function versions to bring in the newer versions from main.
If the version target selected for the branch is published to main before the branch merges, developers must select a new version target and update dependent resources where necessary.
This is similar to keeping a feature branch up to date with changes in the main branch of a Git repository, but the version dependencies also involve Foundry resources.
Advantages and Disadvantages
Advantages
- Related changes can be tested together. Developers can work on supported Ontology changes and the functions that depend on them.
- Safer function releases. Branch-specific versions can be tested before they become stable versions in
main. - Better application testing. Workshop modules and supported function-backed actions can use the branch version during development.
- Fewer manual version updates. Dependents can follow the latest published version when the version target remains unchanged.
- A clearer release path. Teams can review, test, and merge related changes through a shared branching workflow.
Disadvantages
- Repository upgrades may be required. Older TypeScript v2 and Python templates do not meet the documented minimum versions.
- The local Ontology SDK is required. Repositories without it cannot develop function code against branched schemas.
- Not every resource is supported. Global Branching has limitations, including the inability to depend on branched query-function versions in TypeScript v2 and Python repositories.
- Rebasing needs attention. Developers must manage newer versions published to
main and resolve version-target changes before merging.
Common Mistakes to Avoid
Skipping the template upgrade. Check the required parent template version before enabling the workflow. An outdated template can prevent the repository from using Global Branching as expected.
Assuming the Ontology SDK is automatically branchable. The local Ontology SDK is a repository requirement, but the SDK itself is not currently a branchable resource. Follow the supported setup for importing and using branch-specific Ontology definitions.
Testing only the function code. Test the function in its downstream application when the feature depends on how Workshop or an action consumes the result.
Publishing the wrong version target. The version target determines which function version becomes stable after merging. Confirm the intended target before release.
Forgetting to rebase. If main receives a newer function version while the branch is active, review the available update and rebase when appropriate.
Best Practices for Development Teams
Keep related changes in one branch. Include the supported Ontology, function, and application changes that belong to the same feature.
Test realistic cases. Check valid inputs, boundary values, missing properties, and expected error behavior. A successful preview does not guarantee that every production case is handled.
Review the function's consumers. Identify Workshop modules, actions, or other supported resources that use the function. Test those consumers before merging.
Use clear version targets. Choose a stable target for the intended release and avoid changing it unnecessarily during development.
Keep templates current. Follow the documented requirements for TypeScript v2 and Python repositories, including local Ontology SDK setup.
Rebase when needed. Review updates from main before merging, especially when other developers have changed the same function or its dependencies.
Conclusion
Global Branching is now generally available for TypeScript v2 and Python functions in Palantir Foundry. Developers can create functions that depend on branched Ontology changes, preview them during development, and test branch-specific versions in supported downstream applications before merging.
The feature is most useful when a change affects multiple connected resources. Instead of releasing the data model first and hoping the function works afterward, teams can test the related pieces together.
Before adopting it, upgrade the repository templates, enable the local Ontology SDK, and understand how branch-specific function versions become stable after a merge. Those steps help teams use the new workflow without confusing preview versions with production releases.
Join the conversation! Your thoughts help the community grow.