.. _model-filter-criteria: Model filter criteria ---------------------- .. _21.1|VOSS-847: .. _21.4-PB3|VOSS-1230: .. _25.1|EKB-22798: .. _25.1|EKB-23807: .. _25.3|EKB-26144: .. _25.3|VOSS-1507|EKB-26263: .. _25.3|VOSS-1507|EKB-26343: .. tip:: :ref:`use-action-search-to-navigate-automate` Overview .......... Model filter criteria defines how users (for example, Microsoft Active Directory or MS Entra MSOL user) are matched to corresponding data in Automate to move users and related data to the correct system levels (Customer or Site) on import (in a sync or overbuild), based on one or attributes defined for the model type. .. note:: Model filter criteria for LDAP sources is only compatible with Microsoft Active Directory (that is, Microsoft LDAP, not OpenLDAP). Administrator users with access to the ``data/ModelFilterCriteria`` model can manage instances of this model so that these are available for selection in the Site Defaults Doc (SDD) of a site. The SDD provides options to choose a predefined model filter criteria (depending on the user type). Options are: * MS 365 User Model Filter Criteria * Microsoft Active Directory (Microsoft LDAP) User Model Filter Criteria * CUCM User Model Filter Criteria In addition, model filter criteria can also be executed directly, in other words outside of the import (sync or overbuild) process. By default, the administrator's default access profile (for the Automate - Admin role) has the **Permitted Operation** called **Execute** enabled for model filter criteria. This allows for model filter criteria execution to match and move data from the source hierarchy to the specified target hierarchy. .. rubric:: Related topics * .. raw:: latex Flow through provisioning (FTP) in the Core Feature Guide. .. raw:: html Flow through provisioning (FTP) Known limitations for CUCM user model filter criteria '''''''''''''''''''''''''''''''''''''''''''''''''''''' When using CUCM user model filter criteria, filter attributes based on Custom User Fields are subject to a known limitation. CUCM does not read all LDAP user attributes by default. In bottom-up LDAP deployments, if an LDAP attribute that is not natively read by CUCM is mapped into a CUCM Custom User Field, that field cannot be reliably evaluated by model filter criteria during user import, sync, or move operations. As a result, model filter criteria based on Custom User Fields may not be applied, and matching users may not be moved to the expected site. This behavior is expected and is a known system limitation. There is currently no supported workaround to enable the use of Custom User Fields in CUCM user model filter criteria. When defining CUCM user model filter criteria, use only attributes that are directly available to CUCM by default. Create model filter criteria ............................... **Pre-requisites**: * To allow move to work using model filter criteria defined at the Site level, an admin user must enable the following on the **Flow Through Provisioning** tab in the **Global Settings**: * Enable Move & Flow Through Provisioning * Enable Move & Provisioning after Add Sync **Perform these steps**: 1. Identify the source and target model and field that will be used in the filter. #. Go to **Model Filter Criteria**. #. Click **Add** to add a new record, or clone an existing model filter criteria and update it to create a new model filter. #. Provide a **Name**, **Description**, and **Usage** for the filter. For **Usage**: * The model filter criteria with usage set to **Move User** is used to move the user. * Model filter criteria with usage set to **Flow Through Provisioning** is used to provision the user. The flow through provisioning usage does not move a user, and will run only if the user is at a site. * If set to **Overbuild**: * the **Target Hierarchy** drop down is shown, listing the available nodes below the current hierarchy. (For bulk load sheets, enter the full hierarchy path, starting from ``sys``.) * the **Automated Overbuild** check box is available to enable so that only MFCs set to **Automated Overbuild** will then be executed. #. From the **Type** (model type) drop-down, select the source model, for example ``device/msgraph/MsolUser`` (MS Entra MSOL users) or ``device/ldap/user`` (Microsoft Active Directory users). For Microsoft Defender overbuild, select the relevant device model, for example ``device/msexchangeonline/QuarantineMessage`` - see: :ref:`ms-defender-for-office`. .. note:: The model type defines the available attributes you can use in the model filter criteria. #. Click the Plus sign (+) in the **Criteria** group to add one or more criteria. Each criteria is defined by the following: .. tabularcolumns:: |p{5cm}|p{10cm}| +----------------------+-------------------------------------------------------------------------------+ | Field | Description | +======================+===============================================================================+ | Unary Operator | None, or NOT: to operate on the match **Condition** with the target value | +----------------------+-------------------------------------------------------------------------------+ | Attribute | The field from the source model, for example ``City`` from | | | ``device/msgraph/MsolUser``. | +----------------------+-------------------------------------------------------------------------------+ | Condition | Options are exact and non-exact types of contains and equals, as well as | | | a regex search option. | +----------------------+-------------------------------------------------------------------------------+ | Value | The target value that identifies the site in VOSS Automate. The value can | | | also be a named macro, for example, ``{{ macro.OVERBUILD_SITE_CITY_NAME }}``. | +----------------------+-------------------------------------------------------------------------------+ | Conditional Operator | AND or OR: only needed and used to indicate the type of Boolean combination | | | with the following criteria instance, if an additional instance is added. | +----------------------+-------------------------------------------------------------------------------+ 7. Save the model filter criteria. You will be able to choose this new model filter criteria in the site's SDD, and it will be, for example, applied in the Microsoft overbuild if **Include Site for Overbuild** and **Microsoft Users** is enabled. When running the overbuild, the system loops through the site defaults to identify sites with **Include Site for Overbuild** enabled, and moves related user data to the site based on the chosen model filter criteria rule. In this example, all ``device/msgraph/MsolUser`` instances synced in will be moved to the site matching ``{{ macro.OVERBUILD_SITE_CITY_NAME }}`` if their ``City`` value matches. 8. If required, use the **Execute** button to run the model filter criteria in order to move matched data. Microsoft Entra ID groups in model filter criteria ..................................................... For model filter criteria of **Type** ``device/msgraph/MsolUser``, the **Attribute** called ``Groups.displayName`` can be used to create a filter for syncing in and automatically onboarding - move and provision users - based on their Microsoft Entra ID group membership. .. important:: Consider the following when creating filters using ``Groups.displayName``: * The **Value** of the ``Groups.displayName`` attribute should be an exact *case-sensitive* match of the Microsoft Entra ID group name. For example, a **Value** of ``Northwood`` will match ``Northwood``, but will not match ``northwood``, ``Northwoodly``, ``WestNorthwood`` or ``Westnorthwood``. * The **Condition** should be ``Equals Exactly``. * Multiple conditions using the ``Groups.displayName`` attribute are supported, but require the use of ``AND`` as the **Conditional Operator**. All conditions in the filter should therefore be true for the filter to apply; in other words, the user needs to belong to *all* the groups matching the **Value** field. .. note:: * If a *single* matching filter condition is added whereas a user belongs to more than one Microsoft Entra ID group, the user is matched if the filter matches. * If an ``OR`` conditional operator is used, this will be interpreted as an ``AND`` operator. * The ``Groups.displayName`` attribute cannot be combined with other attributes in a filter: other attributes will be ignored. * Verify that these caveats are taken into consideration, since model filter criteria can be saved in the system without their consideration. Additional available model filter criteria for device/msgraph/MsolUser .......................................................................... From release 25.1 onwards, the model filter criteria of **Type** ``device/msgraph/MsolUser`` offers additional **Attribute** values: :: City CompanyName Country Department EmployeeType extensionAttribute1 extensionAttribute10 extensionAttribute11 extensionAttribute12 extensionAttribute13 extensionAttribute14 extensionAttribute15 extensionAttribute2 extensionAttribute3 extensionAttribute4 extensionAttribute5 extensionAttribute6 extensionAttribute7 extensionAttribute8 extensionAttribute9 IsLicensed Licenses.SkuId Office UserPrincipalName UserType The use of these attributes in model instance filters allow for the optimization of sync performance and timing, as well as additional filtering functionality in the list view of ``device/msgraph/MsolUser``. .. note:: By default, model filter criteria with attribute *UserType* and value *Member* is automatically applied to filter the ``device/msgraph/MsolUser`` model sync into Automate from the Microsoft tenant. The default filter then allows only import of real users; that is, members only, and not external/guest accounts (where *UserType* is *Guest*). While the default filter syncs is only *Member* user types, you can adjust the model filter criteria to sync in *Guest* user types from the tenant, if required. Automatic filtering on member users ships with Automate 25.1. Post-upgrade syncs on existing tenants where external/guest users have previously been synced in won't trigger workflow changes and updates to the existing users. Microsoft Defender criteria for overbuild .................................................... If Microsoft Defender for Office is enabled as a service in global settings, additional model filter criteria are added to allow for the move of MS Defender policies, incidents and alerts. See: * .. raw:: latex Microsoft Defender setup, sync and overbuild in the Core Feature Guide .. raw:: html Microsoft Defender setup, sync and overbuild * .. raw:: latex Overbuild for Microsoft in the Core Feature Guide .. raw:: html Overbuild for Microsoft .. rubric:: Related Topics * .. raw:: latex Microsoft Overview in the Core Feature Guide .. raw:: html Microsoft Overview * .. raw:: latex Sync to Site with with Flow Through in the Core Feature Guide .. raw:: html Sync to Site with with Flow Through * .. raw:: latex Flow Through Provisioning in the Core Feature Guide .. raw:: html Flow Through Provisioning