Creator Studio development instance strategy
Summarize
Summary of Creator Studio Development Instance Strategy
The Creator Studio development instance strategy outlines how to effectively manage access and deployment of applications built within ServiceNow's Creator Studio. It is essential for users to install Creator Studio on all relevant instances, including production, to facilitate application development.
Show less
Key Features
- Access Management Options: Companies can choose from three strategies for managing Creator Studio access:
- Open Access: All employees can create apps.
- Restricted Access: Access is limited to select users.
- Request-Based Access: Users must apply for access, with requests reviewed by admins.
- Development and Deployment: It is recommended to use a non-production instance configured like the production instance to test applications before deployment. This helps identify issues that could affect live environments.
- Catalog Configuration: To ensure proper functionality, both non-production and production instances must have identical Service Catalogs and categories.
Key Outcomes
Following this strategy helps ensure that applications are developed and tested in a controlled environment before being deployed to production, minimizing risks and enhancing application reliability. It also streamlines the approval process for deploying applications and ensures that all necessary roles are assigned for testing and fulfilling requests effectively.
By establishing clear instance strategies and access protocols, organizations can maximize the benefits of Creator Studio while maintaining control over application development and deployment processes.
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.