Data policy best practices

Prev Next

Best practices for Helix Enterprise search-based data policies and filters follow.

  • New Helix Enterprise subscribers: Allow a few days of processing before creating data policies to allow values to populate in the Create a New Data Policy dialog.

  • Designate a strict default data policy for your organization and then increase access for individual users as needed.

  • Use the global "private" setting on the Data Policies page to ensure that users cannot see data that their data policies do not allow. If the "public" setting is used, the View Results menu item on the Reports, Archive Searches, and Saved Searches pages will return cached data from the query the owner ran. That data will be visible to all users, even those with a data policy that restricts the data in those results. The user's data policy restriction is only applied to new searches based on these queries, not to cached results. Dashboards run interactively when launched, so the user's data policy is always applied to any dashboard widget results.

  • Set the global "private" visibility setting before assigning data policies to users.

  • Click the syntax in the syntax preview to copy it to the clipboard. Use this in a test search to make sure the data policy rule returns the expected results.

  • A parsing error could cause a class to be categorized as "unknown." Include the constraint class DOES NOT EQUAL unknown in data policies to prevent users from seeing data for classes they are restricted from seeing. The "unknown" class should only be visible to users who perform configuration or troubleshooting.

    Note

    You can only create this constraint if your instance already has an event with a class of unknown.

  • Check regularly for new log sources such as "unknown" and adjust your data policies accordingly.