Documentation
DocumentationDeveloperAcademyCommunitySupportLogin

Moveworks Custom Attributes

Suggest Edits

When Integrating an External system with Moveworks, by default Moveworks contains a standard set of fields that are pre-defined for the system. These fields typically include unique identifiers from these systems (e.g., system IDs) as well as basic details like name, role, manager, etc.

However, there may be situations where you need Moveworks to understand additional attributes apart from the defaults. Custom attributes allow you to extend the current fields capability to new fields which can mapped to their contexts and then used across Moveworks.

Custom attributes must still be imported and mapped from an integration source. If a direct integration is not available for the system you require, alternative import options are provided.

  1. Custom attributes can be utilized in four areas within Moveworks. These are the only places where mappings of custom data are configured:
    1. User
    2. Ticket
    3. Approvals
    4. Knowledge
  2. In order to reference the custom attributes under any context, they first need to be to the Custom Attributes Registry. The guide below will cover the steps of how to do this.
  3. When writing DSL Rules, if you want to use a custom attribute, you must access it using either the custom_data or custom_attributes keyword to ensure the DSL Rule is syntactically correct.
    • Example: If you have defined a custom attribute “has_manager” within the identity module:
      • You cannot directly use user.has_manager in the DSL.
      • Instead, you must use user.custom_attributes.has_manager

How to Register a Custom Attribute

In order to register the Custom Attribute you need to navigate to the Analytics and Data > Custom Attributes Page. On this page you can either add a new custom attribute or edit an existing one under a particular Data Object.

Data Objects are contexts under which custom attributes can be defined, Once the Data Model has been selected we can reference the custom attributes under it.

For ex. we define is_employee as the custom attribute under the User Data Object Type. Now we can reference this attribute under the pretext of user.custom_attributes.<custom_attribute_name>

Below are the different Data Object types which Custom Attributes can be created under :

User Data Object

Custom Attributes registered under the user Data Object can be referenced across DSL fields which support the user context. This is done by using the definition user.custom_attributes.<custom_attribute_name>

In the below example we will define the custom attribute is_employee under the user data Object.

  • Name : Define the custom attribute name here

  • Data Sensitivity Policy Type(optional) : This field defines what the sensitivity policy is for the custom attribute. Based on the choice selected the data will have the following behaviour.

    • Customer Data - Details of the value will be redacted in the logs as this is customer data. The value for the field will be visible in the User Profile View.
    • PII Data - This sensitivity policy hides all the details of the attribute as it is considered Personal Identifiable Information which is redacted in the logs. Value will only be visible in the User Profile View.
    • MW Sensitive Data - Details of the value will be redacted in the logs as this is Moveworks data. This is rarely used by customers and the value for the field will be visible in the User Profile View.
    • MW Non Sensitive Data - Details of the value will be visible in the logs as this is Moveworks data. This is rarely used by customers and the value for the field will be visible in the User Profile View.

  • Customer Data(optional) - This field defines the type of data the customer attribute is, the common kind is CUSTOMER_DATA_USER_DATA. This counts towards analytics in terms of how the data is used by the plugin.

Ticket Data Object

Custom Attributes registered under the ticket Data Object can be referenced across DSL fields which support the ticket context. This is done by using the definition ticket.custom_data.<custom_attributes>

In the below example we will define the custom attribute assignment_group under the ticket data Object.

  • Name : Define the custom attribute name here

  • Data Sensitivity Policy Type(optional) : This field defines what the sensitivity policy is for the custom attribute. Based on the choice selected the data will have the following behaviour.

    • Customer Data - Details of the value will be redacted in the logs as this is customer data. The value for the field will be visible in the User Profile View.
    • PII Data - This sensitivity policy hides all the details of the attribute as it is considered Personal Identifiable Information which is redacted in the logs. Value will only be visible in the User Profile View.
    • MW Sensitive Data - Details of the value will be redacted in the logs as this is Moveworks data. This is rarely used by customers and the value for the field will be visible in the User Profile View.
    • MW Non Sensitive Data - Details of the value will be visible in the logs as this is Moveworks data. This is rarely used by customers and the value for the field will be visible in the User Profile View.

  • Customer Data(optional) - This field defines the type of data the customer attribute is, the common kind is CUSTOMER_DATA_TICKET_DATA. This counts towards analytics in terms of how the data is used by the plugin.

Knowledge Base Data Object

Custom Attributes registered under the Knowledge Base Data Object can be referenced across DSL fields which support the resource context. This is done by using the definition resource.custom_data.<custom_attributes> . The Knowledge base Data model is commonly used across multiple DSL Fields as part of Moveworks Knowledge Ingestion.

This Data Object comes in handy for managing Knowledge post Ingestion where we can write DSL rules to permission how the Knowledge is served.

In the below example we will define the custom attribute managers_only under the knowledge base data Object.

  • Name : Define the custom attribute name here

  • Data Sensitivity Policy Type(optional) : This field defines what the sensitivity policy is for the custom attribute. Based on the choice selected the data will have the following behaviour.

    • Customer Data - Details of the value will be redacted in the logs as this is customer data. The value for the field will be visible in the User Profile View.
    • PII Data - This sensitivity policy hides all the details of the attribute as it is considered Personal Identifiable Information which is redacted in the logs. Value will only be visible in the User Profile View.
    • MW Sensitive Data - Details of the value will be redacted in the logs as this is Moveworks data. This is rarely used by customers and the value for the field will be visible in the User Profile View.
    • MW Non Sensitive Data - Details of the value will be visible in the logs as this is Moveworks data. This is rarely used by customers and the value for the field will be visible in the User Profile View.

  • Customer Data(optional) - This field defines the type of data the customer attribute is, the common kind is CUSTOMER_DATA_KNOWLEDGE_DATA. This counts towards analytics in terms of how the data is used by the plugin.

Knowledge Article Data Object

Custom Attributes registered under the Knowledge Article Data Object can be referenced across DSL fields which support the article context. This is done by using the definition article.custom_data.<custom_attributes> . The article context is very rarely used across Moveworks as only certain fields support the context.

In the below example we will define the custom attribute u_type under the knowledge article data Object. This is very commonly used in the Knowledge Article Filter Rule when doing Knowledge Ingestion to filter out articles from being ingested on the Moveworks end.

This Data Object comes in handy for managing Knowledge Pre-Ingestion where we can write DSL rules to filter out articles from being ingested which is usually done in the Initial Knowledge Ingestion Configuration.

  • Name : Define the custom attribute name here

  • Data Sensitivity Policy Type(optional) : This field defines what the sensitivity policy is for the custom attribute. Based on the choice selected the data will have the following behaviour.

    • Customer Data - Details of the value will be redacted in the logs as this is customer data. The value for the field will be visible in the User Profile View.
    • PII Data - This sensitivity policy hides all the details of the attribute as it is considered Personal Identifiable Information which is redacted in the logs. Value will only be visible in the User Profile View.
    • MW Sensitive Data - Details of the value will be redacted in the logs as this is Moveworks data. This is rarely used by customers and the value for the field will be visible in the User Profile View.
    • MW Non Sensitive Data - Details of the value will be visible in the logs as this is Moveworks data. This is rarely used by customers and the value for the field will be visible in the User Profile View.

  • Customer Data(optional) - This field defines the type of data the customer attribute is, the common kind is CUSTOMER_DATA_KNOWLEDGE_DATA. This counts towards analytics in terms of how the data is used by the plugin.

Using Custom Attributes

Once the Attributes have been defined in the respective context mentioned above, they can be used across DSL Rules in Moveworks Setup. Here is a Guide which walks you through the example DSL Rule Scenarios for Plugins across Moveworks Setup.

Updated about 4 hours ago