Changing the table for an app

  • Release version: Yokohama
  • Updated August 11, 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 flexibility allows apps to leverage existing business logic, handle complex modifications, or integrate with federated app tables. The current table associated with an app can be viewed under the Data management tab in the App settings.

    Show full answer Show less

    Reasons to change the table for an app

    • Utilize existing tables with built-in business logic or specific field handling.
    • Overcome limitations of the default Request App table by using a different, more customizable table.
    • Use tables that inherit components from federated apps for better integration.
    • Consolidate data from new Creator Studio apps into existing large federated application tables.

    Requirements for changing the table

    • The app must already be created before changing its table.
    • It is recommended to use a table that extends the Request Task table to maintain automations.
    • The new table must include a requesttype field labeled "Request type" that references the Record Producer table; missing this field will disrupt automation triggers.
    • If the new table is in a different scope than the app, its scope must permit updates from other scopes.

    Impacts of changing the app's table

    App Component Effect
    Forms If you change the table after forms are created, users will encounter errors viewing forms linked to the old table. To resolve this, revert to the original table or create new forms for the new table.
    Automations Changing to a table lacking the requesttype field prevents adding playbooks and disrupts automation triggers.
    Workspace list configurations Existing filtered lists retain the original table reference. If multiple filtered lists reference different tables, users may experience errors, such as inability 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.