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.
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 :
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
To enable the bot access rule only for users with a valid chat identity, you can use the following rule by checking the external_system_identities on the user object e.g:
Slack:
**Microsoft Teams: **
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 -
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 -
Delete one of the users from the source system. Eg: If John Doe with the email john.doe@company.com and Jane doe with the email jane.doe@company.com have a conflicting “ITSM User Id” then deleting either one of these profiles from the ITSM system will resolve the issue
Filter out these users within the”Configure Selected Users” step of ingesting users.
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:
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:
Navigate to User Identity > Import Users under Core Platform.
Proceed to Configure selected sources step and switch to Advanced mode
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.
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 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 :
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.
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.
Breakdown of the Logic This code block above assigns tags to the user_tags attribute. It uses a FILTER() function to process a list of potential tags and remove any that evaluate to null or empty.
Here’s what each part does:
Here is another common user tag example where users are specified by email address and role:
This configuration will tag specific users as a TESTER to prevent their testing activity from entering the analytics dashboards and tag users with a specific role as VIPs which can be used to filter ticket notifications or other features from applying to those users.
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.
As part of the User attributes which are imported on the Moveworks end during Identity Ingestion, one of the most common attributes utilized by customers is the employee_start_date field. This attribute is used to create Audience groups for sending out Employee Communication messages out to new hires.
To import this attribute field we need to carry out the following steps :
employment_info.employee_start_date_ts which is used to store the employee start date information coming from the source system. This is defined in the Source-Specific User Attribute Mapping Editor in the config.
employment_info.employee_start_date_ts
Note : We are using some functions here like $TIMECONV which converts the ingested timestamp into Moveworks understandable format ans stores it. The IF condition is present to avoid accidental Ingestion failures if the data stops propagating.
In order to validate if the Employee start date information has been ingested, you need to wait for the next ingestion run to take place based on the Ingestion Schedule here. Once ingestion is complete you can verify if Employment Info Employee Start Date Ts has populated for the user record.
You can do this by searching for a user name in the Search field and then checking the Identity Attributes list where the Attribute should now have a value.
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.
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.
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.
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.
profile.assistantName from the source system
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.
Here is an example of what an API Query filter looks like for ServiceNow where we are only fetching the users who :
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.
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.
If your Jira instance has both customer and atlassian accounts for the same set of users, Moveworks User Identity may pick up the wrong record for ingestion.
Add a processor in the jira_service_desk section in the User Identity ingestion like below to do this:
When importing users from Workday as the source system, Using Query filters Moveworks ensures that you are fetching only the data you need. In the case of Workday we need to leverage the Workday Query Language(WQL) in the API call in order to filter the users.
In order to allow Moveworks to leverage WQL in the Filter for Identity Ingestion we need to ensure the configuration option has been selected to enable it.
Now we can define the WQL in the Identity Ingestion Configuration in order to filter out the users.
Now we are good to submit the configuration which will now filter users based on the WQL being provided which will now be leveraged by Moveworks.
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.
The password_meta_info.password_last_changed object is used to calculate when a Password Expiry notification should be sent to a user. This field needs to be mapped to the user roster if using the Access Account plugin.
Navigate to Core Platform -> User Identity -> Import Users.
"password_meta_info.password_last_changed": "$TIMECONV(passwordChanged, NULL, \"%Y-%m-%dT%H:%M:%SZ\", NULL, NULL, FALSE)",
To successfully validate if the password meta info field is populating, you will need to wait for an Identity Ingestion cycle to complete. After this, the Password Meta Info should be mapped to the user roster. You can use the User Identity > Imported Users page to check the user details on a specific user to confirm the data is being mapped properly.
Use this method if you need to map membership of an AD group to access to the AI Assistant.
When configuring the active_directory source in User Identity, under Filters and Attribute List, confirm that memberOf is listed as an attribute.
Under Source User Attribute Mapping , add the following to your mapper and replace with the DN of the group. This will add the HAS_ACCESS_TO_BOT user tag to users who are part of the specified group.
User Identity > Bot Access, add the following rule to ensure only users who are part of this group have access to the assistant:
The Moveworks AI Assistant can provide personalised search results to a User based on their Profile Boosting which relies on the Geocode information for that user to be ingested on the Moveworks end.
In order for the Search results to be personalised, we need to start by ingesting the GeoCode information from the integration system which houses it. Location information could live in any of your integrations (Okta, AD, ServiceNow, Active Directory etc.).
In order to extract this information, You can leverage the User Geocode Processor which pulls the location information of the user and then maps that to the associated GeoCode. Before doing so make sure the below steps have been completed :
Currently, we apply the GeoCode Processor on the country_code field of the Integration. Therefore, it is preferred to have the values be as clean as possible the country name string such as: United States, France, India.
Please Note : Having the abbreviated country codes such us US, CA, etc. Might not work in some cases. For example, the country code IL is ISO-standardized code for Israel, however, the geocode extractor may confuse it with the Illinois state in the USA. We cannot override any geolocation calls.
If you have more than a single Identity System which is using the GeoCode Processor, Please follow the below steps :
You can only ingest GeoCode information from a single Source system so you would need to override the attribute in Override User Profile Fields
Say you have access to the manager’s email. Then you can map it directly by accessing the available key
In the example above, managerEmail would be the key from the external system that we are mapping to manager_email on the Moveworks User object.
However, in most cases you will have access to some other field that references the manager - in ServiceNow we generally have a reference to a ServiceNow sys_id that refers to the user’s manager as seen in the JSON below from the ServiceNow Table API. In Active Directory, you may have the manager attribute that contains the distinguished name of the user who is the user’s manager.
First we map the manager_email field in our user object to the value of the reference field we get from ServiceNow from the manager user reference field.
Then under the identity source mapping, also map sys_id under manager_resolver :
Then enable the UnifiedManagerResolverProcessor for the integration we are mapping.
A common user tag you may want to apply is to specify a TESTER By doing so, we can eliminate this user’s interactions from Moveworks Analytics dashboard. This is common since we may have stakeholders that are using the AI Assistant more often, and we don’t want to include them in our reporting.
Example
In this example below, we check the vip.value field being returned from ServiceNow’s user import to ensure it matches up to TRUE , in that case the user is given the user_tag VIP.
In order to validate if the Employee GeoCode Information has been ingested, you need to wait for the next ingestion run to take place based on the Ingestion Schedule here. Once ingestion is complete you can work with the Moveworks Support Team to check if the Geocode information has been ingested successfully