Plan field filters with data model acceleration (DMA)

If you plan to use field filters with data model acceleration (DMA), consider these questions before rollout:

• Do you need to prevent original sensitive values from being written into accelerated data model summaries, or do you need to restrict the values returned to non-exempt users when they run tstats searches against summaries that already exist?
• Which field name do you need to filter on each data path? To prevent original values from being written into new or rebuilt summaries, configure the field filter on the source field that the DMA search sees. To protect values returned from existing summaries, configure the field filter on the field name that tstats reads from the DMA summary, often a data model field name such as dataset.field.
• Which roles, if any, are allowed to bypass the field filter and see original values where those values still exist, such as in raw events, raw fallback results, or existing DMA summaries?
• Do you need data-at-rest protection for summary .tsidx files on indexers? Field filters can protect search results, but they do not delete or encrypt original values that already exist in DMA summary files.

Test your DMA, tstats, Splunk Enterprise Security (ES) detection, and role-exemption use cases in a non-production environment before enabling field filters in production.

For more information about using field filters with DMA, see Use field filters in searches on accelerated data models.

Next step

Next, plan for how restricted commands are impacted and consider workaround solutions. See READ THIS: Restricted commands do not work in searches on indexes that have field filters.