Creator Studio development instance strategy
Summarize
Summary of Creator Studio development instance strategy
Creator Studio must be installed on all ServiceNow instances where application development occurs, including production. Establishing a clear instance strategy is critical for managing Creator Studio access, development workflows, and app deployment processes within your organization.
Show less
Instance Access Management
Decide how users will access Creator Studio by choosing one of the following approaches:
- Open Access: Allow all company users to create applications.
- Restricted Access: Limit access to specific user groups.
- Request-Based Access: Implement a request form for users to apply, with admins reviewing and approving access.
Development and Deployment Strategy
Use a non-production instance configured similarly to production as the primary development and testing environment to identify deployment issues more effectively.
Developers should build applications in Creator Studio on non-production instances. Once apps are ready and approved, they are deployed to production. Note the difference in data tables used:
- Development uses the System Applications [sysapp] table.
- Production deployment references the Store Apps [sysstoreapp] table.
It is important to automate approval and review processes to maintain control over what is deployed to production.
If multiple non-production environments exist, determine which will host Creator Studio and define pipelines to promote apps from development to test, then production.
Catalog Configuration Requirements
To ensure forms display correctly for end users, both non-production and production instances must have identical Service Catalog configurations, including all catalog categories.
Developer Roles and App Testing
Users with roles sncreatorstudio.user or sncreatorstudio.restricteduser cannot test apps via the non-production instance’s Request App Workspace but can use Creator Studio’s app preview feature.
Testing as a fulfiller in the Request App Workspace is only available on the production instance after app deployment.
Example: A user in the Creator Studio Users group gains delegated development permissions for their app and can submit requests if no special roles are required. However, such users cannot fulfill requests or access the Request App Workspace without the xacmeuserapp.agent role, which must be assigned 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
- 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.
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.