---
title: "Functions change management"
slug: "functions-change-management"
updated: 2026-01-09T19:56:22Z
published: 2026-01-09T19:56:22Z
---

> ## Documentation Index
> Fetch the complete documentation index at: https://support.tulip.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Functions change management

Who can use Functions

          

As of r338, Functions is in Production Early Access. To request access, contact your Customer Success manager.

**Read more in the Community thread [here](https://community.tulip.co/t/functions-production-release-available-for-early-access/15658).**

---

## Changes to inputs or outputs

Breaking change alert:

Adding, removing, or renaming inputs and outputs requires changes to app trigger actions that call the function.

Follow this process to change a function signature:

1. Design the input and output structure carefully before you adopt the function widely.
  - **Inputs:** When you create a function to create a new table record, consider all typical columns that the function should populate upon record creation, not just the columns for the first use case.
  - **Outputs:** Common outputs you may build into a function include:
    - Record IDs of table records that the function creates
    - Operator-visible messages (set into a variable by the function logic)
2. Notify all app builders before you make changes.
3. Update the function systematically:
  1. Change the function.
  2. Test the function with the Test button using representative inputs.
  3. Test the function in one development app end-to-end.
  4. Update each app to map new inputs and outputs.
    - As of r351, there is limited visibility regarding where a function is used (both which apps and where within an app). From an app's Versions tab, you can see what functions a version uses.
    - For apps that use a function, click the View errors button in the app editor. A modal displays any function references in the app that are broken.
  5. Test each app in developer mode.
  6. Publish the apps.

### Alternative approach for major changes

Create a new function with an updated signature and migrate apps gradually:

1. Create a new function version with new inputs (for example, CreateSample_v2).
2. Migrate high-priority apps to the new version.
3. Migrate remaining apps over time.
4. Deprecate and archive the old function version.

## Change internal function logic

Info

Changes to internal function logic (decision trees, calculations, table operations) do not break apps. However, you need to publish apps with a new version to associate the new function logic.

Follow this process:

1. Update the function logic.
2. Test the function with the Test button using representative inputs.
3. Test the function in one development app end-to-end.
4. Publish a new version of the apps to associate with the updated function.
5. Monitor production apps for unexpected behavior.

**Best practice:** Use an approval workflow procedure for functions used in production apps.

---

## Additional Resources

### Tulip Library

- [Tulip Library Functions](https://library.tulip.co/search?section=Functions)

### Tulip Community

- [Tulip Community Functions posts](https://community.tulip.co/tag/functions)

---

Did you find what you were looking for?

You can also head to [community.tulip.co](https://community.tulip.co/?utm_source=intercom&utm_medium=article-link&utm_campaign=all) to post your question or see if others have solved a similar topic!