Creator Studio development instance strategy

  • Release version: Zurich
  • Updated July 31, 2025
  • 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 Creator Studio development instance strategy

    Creator Studio should be installed on all ServiceNow instances where users build applications, including production. A clear instance strategy is essential for managing access, development, testing, and deployment of Creator Studio apps effectively within your organization.

    Show full answer Show less

    Instance Access Strategy

    • Open Access: Allow all users in your company to create apps using Creator Studio.
    • Restricted Access: Limit app-building capabilities to specific user groups.
    • Request-Based Access: Implement an access request form that admins review before granting Creator Studio usage.

    Development and Deployment Best Practices

    Develop apps in a non-production instance configured similarly to production to accurately identify potential deployment issues. Developers should build apps on non-production instances using the System Applications [sysapp] table, then deploy approved apps to production where they appear in the Store Apps [sysstoreapp] table.

    Establish and automate an approval or review process where admins deploy apps from non-production to production environments. For organizations with multiple non-production instances, decide which instance runs Creator Studio and define pipelines for promoting apps through testing to production.

    Catalog Configuration Requirement

    Ensure that both non-production and production instances share the same Service Catalog and all categories so that app forms render correctly for users.

    Developer Roles and App Testing

    • Users with roles sncreatorstudio.user or sncreatorstudio.restricteduser cannot test apps in the non-production Request App Workspace but can use Creator Studio’s app preview feature.
    • Testing fulfillment of apps occurs in production, where users with appropriate roles (e.g., xacmeuserapp.agent) can access the Request App Workspace.
    • Developers who build and publish apps can submit requests if no roles are required, but they cannot fulfill requests or access the fulfillment workspace unless assigned additional roles by administrators.

    Make sure to install Creator Studio on all ServiceNow instances where users will be building applications, including the production instance.

    Deciding on your instance strategy

    You need to decide how you want to manage access to Creator Studio within your company. Consider the following options:
    • Open Access: Allow everyone in your company to use Creator Studio to create apps.
    • Restricted Access: Limit access to a specific group of users.
    • Request-Based Access: Set up a form where users can apply for access. Admins will review these requests and decide whether to grant access.

    Development and deploying to production instances

    A non-production instance that is similarly configured to your production instance may be the best candidate for your test environment. You can then more accurately find issues that may arise if the application is deployed to production.

    You should ensure that developers build apps in Creator Studio on a non-production instance, and then deploy apps that are ready and approved to production.

    When you deploy an app, the records are referenced in the Store Apps [sys_store_app] table on the production instance. But when you're developing an app, the records are referenced in the System Applications [sys_app] table. So if you develop in production, you're developing using the [sys_app] table instead of [sys_store_app].

    After you establish your instance strategy, you must also establish and automate your approval or review process. Creator Studio runs on your non-production environment, and admins then deploy apps to the production environment. For more information on the deployment process, see Deploying your Creator Studio app.

    If your organization has multiple non-production environments, you must decide which non-production environment Creator Studio will run on. You must also determine which pipeline to use for promoting apps from a particular non-production instance to your test instance, and then finally to production where the app will be running live. For more information, see Pipelines and Deployments.

    Catalog configuration requirement for Creator Studio

    To ensure that forms appear correctly for users, the non-production and production instances must have the same Service Catalog and all of its categories.

    Developer roles and testing apps on instances

    If you have a Creator Studio role of sn_creatorstudio.user or sn_creatorstudio.restricted_user, you won't be able to test the apps you build on the non-production instance's Request App Workspace. You should be able to test the app on the non-production instance using Creator Studio's app previews. You will be able to test the apps as a fulfiller in the workspace on the app that's been deployed to production.

    Use case:

    Let's say that a user is in the Creator Studio Users group, so when that user builds an app, that user gets delegated development permissions for that app. That user can then publish a request form, and if there are no roles required for the form, that user can submit requests with the form.

    However, that user won't be able to fulfill requests or access the Request App Workspace because that user won't have the x_acme_user_app.agent role, and that user can't give that role to themself. Administrators must assign additional roles as necessary.