Script Development Lifecycle Management

CXone Studio provides tools to help you manage your script development lifecycle: 

• Script promotion through development workflow stages, such as development, testing, and production.
• Integration with a third-party version control system. Currently, GitHub is the supported provider.
• The ability to view a script's change history and revert to past versions in CXone Studio or Desktop Studio.

Software Development Lifecycle in CXone Studio

In software engineering, many organizations follow methodologies that use a multi-stage approach to development. In these methodologies, the software development lifecycle (SDLC) consists of stages for planning, designing, developing, testing, and deploying software changes. Following a multistage SDLC methodology helps improve the quality of the end product and streamline the development process.

To help you manage your script development lifecycle, CXone Studio provides built-in development workflow stages. This can benefit your script development processes because: 

• Access to scripts at each stage is protected by permissions. This gives you control over which Studio users can interact with scripts based on their development stage.
• Scripts must be promoted from one stage to the next as they progress through the development process. The ability to promote scripts is controlled by permissions, so you can limit who can promote scripts.
• Scripts can be copied down to a lower stage. This is helpful to ensure you're starting from the most current version of a script when it requires changes or enhancements.
• You can establish requirements that must be validated before a script can be promoted to the next stage. For example, you might require all scripts to be peer reviewed and tested before moving into pre-deployment. Promotion requirements are not built into Studio. They are policies and procedures your company must implement outside of Studio.

Using development workflow stages in CXone Studio helps protect your CXone system from unexpected issues caused by scripts. It reduces the chances of incomplete scripts or scripts that aren't fully tested from being put into production.

CXone Studio Development Stages

In CXone Studio, the development workflow consists of four built-in stages:

• Development
• Testing
• Pre-Deployment 
• Production

You can enable the stages that align with your company's script development processes. For example, if you don't use test or pre-deployment stages, you can omit those and only enable development and prod. If your company doesn't have an established multistage development process, you can use the built-in stages as you plan your script development lifecycle.

Each stage is associated with a folder in CXone Studio. All scripts currently in a workflow exist in that folder. When a script is promoted to the next stage or copied down to a lower stage, it's copied into that stage's folder.

The names of the built-in stages cannot be changed. However, when you create the folders for each stage, you can name them whatever you like. The folder names appear in the UI when Studio users promote or copy down a script. For example, if your company uses the name Staging for the pre-deployment stage, you can create a folder called Staging and assign it to the pre-deployment stage in CXone Studio.

You can build your own automation to use with Studio development workflow stages using tools such as Jenkins.

Script Promotion

Studio users with the Promote To permission for a development workflow stage can promote scripts from the previous stage to that stage. Scripts can only be promoted to the next stage that's enabled in your CXone system. They cannot skip stages.

Scripts can also be copied down to earlier stages. This is helpful when a script requires changes or enhancements. For example, if a defect is found in a script in the pre-deployment stage, you can copy it down to the development stage to correct the issue. The script must then go through your company's workflow processes before it can be promoted to pre-deployment again. No permission is required to copy a script down to earlier stages. However, users must have the View permission for the stage's folder they're copying the script from.

When a script is promoted or copied down, it's copied into the destination stage's folder. This means scripts can end up with versions in every stage's folder. If there's already a version of the script in the next level's folder, it's overwritten. It's important to promote or copy down from the correct stage's folder. If you're not sure which version to copy down, you can use the version history of the script at each stage to determine which version you need to promote or copy down.

Scripts can be promoted from the script's canvas or from the Scripts page in CXone Studio. On the Scripts page, you can promote more than one script at the same time. If you've configured CXone Studio with a third-party version control system, promotions are also committed to the specified repository.

Script Version Control

Version control allows you to track and manage changes to your scripts during their development. This allows you to research problems when they arise. If necessary, you can revert to a previous version of a script as a way of undoing a problematic change.

CXone Studio provides two options for script version control: 

• Third-Party Version Control Systems: CXone Studio can commit script changes to a third-party version control system. Currently, GitHub is the only supported provider. This feature is part of a Controlled Release program. Contact your CXone Account Representative if you're interested in knowing more.
• Script History: Studio keeps a configurable number of past versions of each script. Each time the script is saved, it creates a record of that historical version. You can view previous versions and revert to them if needed. This option is supported in Desktop Studio and CXone Studio. This feature is not part of the controlled release program.

The two options for script version control work alongside each other. If you use a version control system, you can still view and revert to the past versions of a script that Studio keeps. 

Similarly, if you use development workflow stages in CXone Studio, you can view past versions of a script. However, the past versions are limited only to the versions from each stage. To view the past versions from a different stage, you must view the script in that stage. Viewing scripts in different stages requires that you have permissions to work in that stage.

Third-Party Version Control Systems

You can use a third-party version control system with CXone Studio. When you connect a repository to CXone Studio, changes to each script are committed to that repository. All changes are committed to the main branch. CXone Studio currently only supports single-branch development.

The first time CXone Studio users attempt to commit changes to a repository, they are prompted to enter an access token for that repository. After they're authenticated with the system, they are not prompted for credentials again unless CXone Studio encounters a problem and needs to re-authenticate the user.

This feature is only supported in CXone Studio. For this reason, only the JSON version of each script is saved in the version control system.

Non-Script Files

Version control is only available for script files. Other files, such as ASR Allows contacts to respond to recorded voice prompts by speaking, pressing keys on their phone, or a combination of both. grammar files or pre-recorded audio prompt files, do not have saved historical versions. They also cannot be tracked in a third-party version control system such as GitHub. To track versions of non-script files, you can use a named-based version management approach.

In the name-based version management approach, you include a version name or number in the file's name. For example, greetingPrompt_v1.wav. When you make changes to the file, you save a new copy with an updated version number. For example, greetingPrompt_v1.wav would become greetingPrompt_v2.wav.

You cannot change the names of these files in CXone. However, you can download the file to your computer, rename it, then upload the new version. You can delete versions of files you no longer need.

Organizations

When you set up your development workflow, you must create an organization in CXone Studio. The organization defines one set of stages and the folders associated with them. It also defines one third-party version control system repository, if you use that option.

You can create additional organizations. Organizations can map to different teams, lines of business, or other delineations in your company. You may want to create more than one organization if your company:

• Wants to use more than one repository for its scripts.
• Uses different development workflow stages in different groups or teams.
• Wants to keep scripts from different lines of business separate from each other.

Each organization has its own folder in your CXone system. All scripts for each organization are stored in that folder. Within each folder, you create subfolders to hold the scripts at each development workflow stage you use. Each workflow stage's folder can have additional subfolders in it. If you have multiple organizations, your folder structure in Studio would look similar to the following example: 

• \Classics
  • \Dev
  • \Test
  • \Staging
  • \Prod
• \ClassTexts
  • \Develop
  • \UAT
  • \Prod

You can configure script security as needed for each organization. Views Allow you to control the information users can see in CXone. and Studio permissions provide a granular level of control over who can access and interact with your company's scripts.