How To Configure Bot Access Rule for Users

This feature control allows users to enable or disable the bot access for your employees. You can enable it for all the users that you have ingested, or enable for some of them, or disable for some of them. This can be done by writing DSL rules under this feature control. Click this link to learn how to write DSL rules.

• Setting the value TRUE in the rule field enables access to all the Enabled Users in the Moveworks Platform.
• Setting the value FALSE in the rule field disables access to all the users in the Moveworks Platform.

You can also write DSL rules using the attributes list in the field like below :

Here is the list of attributes under the user category which can be used to write the rule and permission them based on identity data.

In the below example we are using the user email to filter the users but we can also use any of the other attributes and provide a list of them :

user.email_addr IN ["[email protected]", "[email protected]"]

Validation

Once the rule has been set click on the Validate Syntax button to ensure the rule has been written correctly before testing the Rule using the Run Button.

Clicking on the Run Button opens a new view where we see a preview of the rule we are testing against. Keep in mind this preview rule is not editable, you will have to make the change on the DSL Editor rule.

Select User - Search for users in the Moveworks platform which the rule can be tested against. Only one user can be selected at a time.

Here is an example of the Rule being tested for a TRUE Case.

Here is an example of the Rule being tested for a FALSE Case.

How To Filter out Duplicate Users

While importing users from the source systems, certain attributes need to be unique for every single user in order for the Moveworks to be able to function as expected. These attributes are the following -

1. Email Address
2. Identifier in the ITSM system (Jira, ServiceNow etc.)
3. Email in the ITSM system
4. Identifier in the Chat system (Slack, Teams etc.)
5. Email in the Chat system
6. Identifier in the IDAM system (Active Directory, Okta etc.)
7. Email in the chat system

In case any of these attributes are the same for two or more users then Moveworks will not import identity information for any user until this issue is resolved.

Within the “Duplicate Users” tab you will have the option to download a csv list of users that have one or more of these attributes conflicting with another user.

In the csv file, the “email”, “first name” and “last name” columns display information that identify the users that have the same attributes, the “Conflicting Key” column will indicate the system (ITSM, IDM, Channel) from which these attributes are being imported. You have two options to resolve this issue -

1. Delete one of the users from the source system. Eg: If John Doe with the email [email protected] and Jane doe with the email [email protected] have a conflicting “ITSM User Id” then deleting either one of these profiles from the ITSM system will resolve the issue

2. Filter out these users within the”Configure Selected Users” step of ingesting users.

   1. Go to “Advanced Mode” and identify the system from which a user needs to be filtered out
   2. Add a processor within the system and in the dropdown select “User Filter Processor”
   3. Specify the attribute for which you want to provide the value. This will usually be of the form “integration Id.external_id” eg: ms_graph.external_id. (External Id is the unique id for a particular user within this system)
   4. Enter the ids that need to be filtered out. These can be retrieved from the downloaded csv file in the “Conflicting Key” column. You can decide which user you want to filter
   5. Click on submit and verify this has been successful by checking the status of user ingestion after a few hours

Example

From the table it is clear that the ITSM User Id Attribute is the same for two accounts. The ITSM system is Jira for the above organisation so within MW Setup this is what filtering will look like:

Validation

• Once the users have been filtered out wait for the next ingestion run to take place based on theIngestion Schedule here. Once that is complete you can check the Imported Users view where the Duplicate user count should be 0.

How To Find the source of an Identity Attribute

In the Imported Users View we have a section which includes all the Attributes being ingested.

Due to engineering limitations, we cannot expose what source the attribute is coming from in the attributes table. In order to understand the source of an attribute, admins can:

1. Navigate to User Identity > Import Users under Core Platform.

2. Proceed to Configure selected sources step and switch to Advanced mode

3. Scroll to the bottom of the page and review the Override User Profile Fields Mapper to confirm if the attribute you are searching for has been overridden with another source.

   1. For eg. If the primary source is Okta and I want to know the source for “Phone number” attribute, I will first go the override user profile fields config to check the config. If the attribute is found here, the source will be as per the entry in the this config.
      In the below mapper the data is coming from slack as the source.

      

4. If the attribute you are looking for is not present in the override bender, then the source of the attribute is going to be the primary source of user identity.

5. Note: The troubleshooting steps slightly differ in case of custom attributes. Custom attributes are generally defined in the Source-Specific User Attribute Mapping config of that identity source.

How To Define overrides for Identity Attributes

When configuring Identity Ingestion, In the first step we define the external sources which will be connected to in order to ingest the user identity data from them. Please ensure the required connectors have been created to interact with the source systems.
If not, please follow this guide for Access Requirements in the source system and the steps to Setup Connectors.

We have a categorisation under the sources here which is split between the Primary Source and the Secondary sources. When we are ingesting user data from multiple sources, they all would have some similar attributes like Email, Phone Number, Department, Manager email etc.

The data for all these attributes will only come from the Primary source unless we override the final User Mapper to include the attributes and map them to the secondary sources.

• In order to do this as part of the Configure selected sources we need to switch to the Advanced mode.
• Look for the Override User Profile Fields Mapper, where the user will need to define the override for the attributes.

In the below example ServiceNow is the Primary source but the customer wants the the first_name info to come from Microsoft Graph instead. In order to do this :

• Ensure the required attribute is being mapped in the Source-Specific User Attribute Mapping for Microsoft Graph, this is crucial before we can use this source as an override. In this scenario we need to ensure the first_name attribute is being mapped

  

• Once the attribute has been defined in the source mapper, we need to add this attribute in the Override User Profile Fields as below. We need to define the source name where the attribute is coming from and the attribute name

  "first_name": "ms_graph.first_name"
  

Validation

In order to validate if the attribute data is now coming from the secondary source system would need an Identity Ingestion cycle to complete. Post this you can visit the Imported Users View and search for the user to go into their Profile View.
Here you would be able to view the value of the Attribute and confirm if this is as expected.

How To Configure User Tags based on Conditions

When permissioning users across the Moveworks Platform, it is easy to use the common attributes like email, name etc. to write the DSL rules and maintain a list. This however means that admins would need to manage these rules and maintain them actively to avoid any issues in the AI Assistant.

But what if we could define a Tag to all the users based on a condition and leverage this tag when writing the DSL Rules that would apply to all the users. This is where we can utilise the Moveworks DSL Language in a more advanced manner.

In order define User Tags we need to navigate to the Import Users Configuration and go to the Configure selected sources step where you need to switch to the Advanced mode.

In the Advanced view you would need to add the user tag in the below format in the Source-Specific User Attribute Mapping JSON field. Here is an example of how Moveworks can assign different User Tags defined here using a Conditional Rule.

"user_tags": {
    "FILTER()": {
      "items": [
        "\"BASIC_USER\"",
        {
          "CONDITIONAL()": {
            "condition": "(memberOf AND (\"CN=Moveworks-Admins,OU=CO Objects,OU=Corporate,DC=internal,DC=moveworks,DC=com\" IN memberOf))",
            "on_pass": "\"HAS_ACCESS_TO_BOT\""
            "on_fail": "\"VIP\""
          }
        },
        {
          "CONDITIONAL()": {
            "condition": "((\"[email protected]\" IN email))",
            "on_pass": "\"EXECUTIVE\""
          }
        }
      ]
    }
  }

Here is a Filter rule based on conditions and the pass and fail outcomes of which user tag is assigned to the users who evaluate the rule.

Validation

In order to validate if the User Tag has been assigned to a user, Moveworks would need an Identity Ingestion cycle to complete. Post this you can visit the Imported Users View and search for the user to go into their Profile View.
Here you would be able to view the user tags assigned to the user under the User preferences section.

How To Configure Custom Attributes for Identity Ingestion

When ingesting identity attributes from source systems, you may come across some attributes which are custom to the system and are not recognised by Moveworks, this could range from unique IDs for the records, or a Division ID which needs to be ingested on the Moveworks end.

• In order define Custom Attributes we need to navigate to the Import Users Configuration and go to the Configure selected sources step where you need to switch to the Advanced mode.
• In the Advanced view you would need to add the custom attribute in the Attribute list first in order for it to be fetched in the API call. In the below example we have added legal_entity in the Attributes list.

Next we need to map this custom attribute In the Source-Specific User Attribute Mapping JSON field. Here is an example of how we have defined it in the mapper. When doing this ensure there is a Custom Data attribute defined on the Moveworks end as well to house the info in.

• In this case we are calling it legal_entity which we will also need to add to the Attribute directory in a later step.

    "legal_entity": "$TRIM(IF u_legal_entity THEN u_legal_entity.display_value OR \"\" ELSE NULL)"

Once the mapping has been completed, Moveworks needs to recognise the attribute internally so this needs to be added to the Custom Attributes Config which can be found under Analytics and Data.

• Moveworks requires the custom attribute to be added to its internal registry.
  • Model Type : User Data Model
  • We then need to define the Name of the Attribute which was defined in the previous step (legal_entity).
  • Data Sensitivity Policy Policy Type : Customer Data
  • **Customer Data : CUSTOMER_DATA_USER_DATA**

Validation

In order to validate if the custom attribute has been ingested, Moveworks would need an Identity Ingestion cycle to complete. Post this you can visit the Imported Users View and search for the user to go into their Profile View.
Here you would be able to view the attributes ingested for the user under the User Identity Attributes section. If the ingestion is successful we will see the field listed under here.

How To Filter Users based on Source System API Query

When importing users from the source systems, Using API query filters in systems like ServiceNow has substantial benefits, including improved performance, efficiency, data accuracy, security, and cost savings. By applying filters to your API queries, you ensure that you are fetching only the data you need, making your integrations smarter and more efficient.

Filters can be applied in a bunch of different ways within Moveworks, which can be done post ingestion or prior to ingestion taking place. In this example we are using an API query filter which is configured pre-ingestion for ServiceNow.

• In order to define a filter for the source system, we need to navigate to the Import Users Configuration and go to the Configure selected sources step where you can click on the edit icon for the respective source.
• This will open up the "Filters and Attribute List" section which you can add by clicking on the "+" icon. Here is where you can define the API Query to be used for filtering out the ingestion data.

Here is an example of what an API Query filter looks like for ServiceNow where we are only fetching the users who :

• Are Active
• Email is not empty
• Email is not equal to [email protected]

active=true^emailISNOTEMPTY^u_legal_entityISNOTEMPTY^[email protected]

❗️

API Query filtering is only supported by some source systems like Microsoft and ServiceNow.

If you are running into issues with defining filters, Please reach out to Moveworks Support Team.

Note : Always ensure to test the filter using API Tester tools like Postman to ensure that the data is being returned as expected before defining it on the Moveworks end.

Validation

In order to validate if the ingested user data is respecting the filter which was defined, Moveworks would need an Identity Ingestion cycle to complete. Post this you can visit the Imported Users View and search for the user to go into their Profile View.
Here you would be able to view the ingested users by downloading the CSV file for "List of Enabled Users" where you can search by user emails to ensure they have not been ingested during the cycle and are respecting the filter.