Changing the table for an app

  • Release version: Yokohama
  • Updated June 16, 2026
  • 2 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Changing the table for an app

    Admins using Creator Studio can change the underlying table that an app saves its requests to. This capability allows leveraging existing tables with specific business logic or integrating with federated apps. The current app table can be viewed and managed via the Data management tab in App settings.

    Show full answer Show less

    Reasons to Change the Table

    • Utilize existing tables containing business logic or specific field handling.
    • Bypass limitations of the default Request App table by using a more customizable table.
    • Integrate with tables inheriting components from federated apps.
    • Centralize data into a large federated app by directing new Creator Studio app data into its tables.

    Requirements for Changing the Table

    • The app must already be created before changing its table.
    • Best practice is to use a table extending the Request Task table to maintain automation compatibility.
    • The new table should include the requesttype field, labeled "Request type," referencing the Record Producer table, ensuring automations trigger correctly.
    • If the table belongs to a different scope than the app, it must allow cross-scope updates.

    Impact of Changing the Table

    App Component Effect
    Forms Existing forms linked to the previous table will cause errors if accessed after a table change. Users must either revert to the original table or create new forms tied to the new table.
    Automations If the new table lacks the requesttype field, playbooks cannot be added, disrupting automation workflows.
    Workspace List Configurations Filtered lists maintain the original table even after a change, potentially causing errors if multiple lists use different tables. Users may lose the ability to manage columns without edit access.

    Admins can change the underlying table for an app built in Creator Studio. That is, you can change the table that the app saves its requests to.

    View the current table for the app by selecting the Data management tab in the App settings. For more information, see Edit an app's settings in Creator Studio.

    Reasons to change the table for an app

    Some reasons that you may want to change the table for an app include:
    • You have an existing table that has business logic or handling of specific fields, you can have the app write to that table to use the existing logic.
    • You can't extensively modify the Request App table, so you may want to make more complex modifications and use a different table.
    • You want to use a table that inherits components from a federated app.
    • You already have a large federated application and want to put data from the new Creator Studio into that federated app table.

    Requirements for changing the table for an app

    The app must already be created before you can change the table for it.

    A general guideline is to use a table that extends the Request Task table.
    • If you change an app's table to one that doesn't extend a Request Task-extended table, it could affect automations.
    • If the new table doesn't have the request_type field, the app's automations won't be correctly triggered.
    • The request_type field for the new table should have the label Request type, and it should be a reference to the Record Producer table.
    • If the new table isn’t in the same scope as the app, the scope of the table must allow updates from other scopes.
    For more information on the Task table, see Working with the Task table.

    Repercussions of changing an app's table

    The following table describes how different parts of building an app in Creator Studio are affected by changing the app's table.
    Table 1. How changing the table affects parts of an app
    Part of building an app Effect
    Forms If you change the table for an app after a form is created, users get an error when they view a form that was created against a table that's different from the app's current table.

    In that case, you should change the table back to the original table, or users should create new forms that use the new table.
    Automations If you change the table to one without the request_type field, users can't add a playbook to the app.
    Workspace list configurations If you change the table after a user created a filtered list, the filtered list retains the original table.

    If multiple filtered lists use different tables, users will get errors based on those discrepancies. For example, they can't manage columns for a table that they don't have edit access to.