Changing the table for an app
Summarize
Summary of Changing the Table for an App
Admins can modify the associated table for an app created in Creator Studio, allowing the app to save requests to a different table. This can be done through the Data management tab in the App settings, and it is advisable to use Guided Setup for an easier process. Changing the table may be necessary for utilizing existing business logic, modifying complex fields, or integrating with federated applications.
Show less
Key Features
- Two methods to change the associated table: Guided Setup for ease, or manual updates through the ServiceNow AI Platform.
- Requirements include having an existing app and using a table that extends the Request Task table to ensure proper automation.
- Changing the requesttype field is permissible, provided the user has the appropriate admin roles.
Key Outcomes
- Changing the app's table may affect forms, automations, and workspace list configurations. Users may encounter errors if forms are linked to different tables or if automations depend on specific fields.
- It is crucial to ensure that the new table maintains compatibility with the app's requirements to avoid disruptions in functionality.
Admins can change the associated 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.
- You can use Guided Setup, which is an easier, more streamlined process. For more information, see Configure the table for Creator Studio apps.
- You can update several tables on the ServiceNow AI Platform. For more information, see Change a Creator Studio app's table.
Reasons to change the table for an app
- 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.
- 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.Note:You can change the Request type field, which specifies the form, on the Request Task table or a table that extends Request Task. To do so, you must be an admin or have the sn_creatorstudio.configuration_admin or sn_creatorstudio.task_admin role.
- 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.
Role for changing the table for an app
To change the associated table for an app, you must have either the admin role, the sn_creatorstudio.app_configurator role, or sn_creatorstudio.configuration_admin, which are granular admin roles. For more information, see Granular admin roles.
Repercussions of changing an app's table
| 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. |