Configure Software Catalog

For each software needed for provisioning, it is required to create a new Software catalog configuration.

In the home screen of Software Catalog, you can see a list of already configured softwares or apps. Clicking on Create will open the configuration screen for Software catalog. Let’s understand what these configs mean.

1. Name: This is the unique identifier for your software or app.

   ⚠️ Important Note

   Use the search input for this config to find the software/application entity you want to configure. These entity names are identifiers that are unique to Moveworks and serve our entity detection models to predict which application a user is referring to. To configure organization-specific entities, contact Moveworks Support.

2. Enable In Bot: This switch allows or disallows the app within the bot. This switch overrides any rules set in the “Access Rule” field. Choosing “off” turns off the bot, regardless of any other settings.
   Example: on (to enable), off (to disable)

3. Access Rule: This is a DSL rule for controlling access to the app. The rule can include information about the user, such as user’s location or role. Note: DSL configs are currently in the process of migration. This DSL rule will be made available to the customers shortly.
   Example: user.location == ‘US’

4. Admins Email Address: This field is for entering the email addresses of the admins who have the privilege to provision the app. Multiple addresses should be separated by commas. This field needs to be configured when the provisioning method is
   Example: johnsmith@example.com, janesmith@example.com

5. App Links Pretext: This field is for writing a brief introduction or context about the links that are related to the app.

6. External links relating to the app request: This field should include any external links that are related to the app. These links can include resources, FAQs, etc.
   Example: http://example.com/FAQ, http://help.example.com

   1. URL: This field should include the URL for the external link.
   2. Link Text: This text will be displayed as the human-readable name for the URL. It gives users a preview of what to expect when they click the link.
      Example: Spotify Homepage

There are 3 type of provisioning strategy available for an application which you can select from. Each strategy comes with its own advantages and should be chosen depending on your org’s requirements, software’s capabilities, the type of app, among other factors.

1. Group Based Provisioning: This strategy involves assigning the application to a pre-selected group of users.

   • Integration Id: This is the ID of the integration in your system that contains the group related to the app. Select the Integration ID corresponding to your Identity system i.e. Okta or Azure Directory.
   • External Id: This is the ID assigned by your Identity system to the group associated with the app.
   • Base Config Approval Key Type: This is the approval process to follow when granting user access to the app. Depending on your system, there are different models of approval processes available.
   • Custom Key: Here you can add your custom expression to use for the approval strategy.
   • Base Config Questions: You can include additional questions to gather more information from the user before they can submit a request for the app.
   • Disable Provisioning: Set to true if we should not provision the app to the user, even if their request is approved.
   • ITSM Workflow Assignment Type: This field indicates whether the system should assign a ticket to a specific user (Assignee) or a group (Assignment Group) for the workflow.
   • Form Id: This field can be used to provide the ID of a form in your ITSM, This form will then be filed during the software provisioning flow. This field is specific to ServiceNow.
   • Post Provisioning Messages: These fields are for conveying messages to the user after the app has been provisioned successfully. You can set a title, body and instructions for users who already had access.

2. Role Based Provisioning: In this strategy, users can choose the role they want from a list of available roles when requesting access.

   • Roles: Here, you will provide a list of all the roles that a user can choose from along with details like canonical name, description, user-facing name and external id.
   • Default Role Canonical Name: Here, set the name for the default role which will be highlighted when a user is selecting a role.
   • Role Based Provisioning Hint: This is a guiding statement to the users, suggesting which role might be suitable for them.
   • For other fields related to approval process, ticket assignment, form ID and post provisioning messages, please refer to the explanations provided above under Group Based Provisioning.

3. Self-Service Provisioning: As the name suggests, this strategy allows users to self-serve or provision the app themselves.

   • Title: Enter a high-level title related to self-service provisioning of the app.
   • Body: Provide information that guides the user on how to provision the app themselves. Tip: Several customers add self-service links in the message body.