1. In the Agent Browser UI, clieck the Navigation Menu icon, then select Configuration > Site Configuraiton > Data Lifecycle Policies
2. Click the tile of the object you wish to create the policy for (Report-based policies are available only for incidents, contacts, organizations, and custom objects).
3. Click Add New
4. Click the radio button for Report Based Policy
5. Name the policy
6. Click the Enabled check box to enable the policy and confirm the warning. Note: this step is optional while you are setting up the policy but will eventually need to be completed for the policy to go live. 
7. Select the report you want to use for the policy. Validation is performed to verify the report uses the policy's object type. A message displays if it doesn't and you will need to select a different report. Otherwise, the selected report's tables and filters display. Note, once the policy is enabled this drop-down will be greyed out and cannot be modified in the future. Instead a new policy would need to be created to change the report association.
8. To view the report and see the records that it returns, click Launch Report. While this step is optional, we recommend viewing the report to ensure the records it returns are the ones you want the policy to remove.
9. Click THEN (or the arrow next to it) to expand the action section.
10. Select the desired option from the drop-down list.
11. Click Save to save the new policy.

Best Practices:

When you create a report to use with Data Lifecycle Management, we recommend using these best practices to ensure the report runs efficiently and returns the records you want.

• Use a report with only one output level—Using drill-down levels in the report can have unintended consequences and should not be used with data lifecycle policies.
• Use default filter values that return only the records you want—Your report should return the records you want without requiring you to change search options. Using a report that requires you to first select or change search options can result in the wrong records being targeted by the data lifecycle policy.

• Run the report on the operational database—The operational database stores the records on your site that are actively added, edited, and deleted. However, reports can also run on the report database, which is a snapshot of the data in the operational database. This can include records that have been deleted from the operational database since the report database was last updated. To confirm your report uses the operational database, edit it and review these settings:

  • Allow Server to Change the Data Source as Necessary—This check box must be clear.
  • Set Report to Deferred Execution—This check box must be clear.
  • Data Source—The Operational Database radio button must be selected.

• Use a public report—Private reports can't be accessed by other staff members if they need to review why certain records were targeted by the data lifecycle policy. You can limit report permissions on a public report to ensure only the appropriate staff members can view it.
• Don't use a report with a custom script—Custom PHP scripts in a report can have unintended consequences and should not be used with data lifecycle policies.
• Test the report before you use it—Your report should run quickly enough to avoid timeout issues and should return only the records you want to target. A report with a query that takes a long while to run is placed in a deferred execution mode and the data lifecycle policy is invalidated. You can use the report analyzer to see why a report might run too slowly or encounter timeout issues.
• Use more than one report if necessary—If your report correctly targets the records you want to purge or delete but still encounters timeout issues or attempts to process too much data, refine the filters to target only a subset of the records you want. You can later create other reports, or modify the existing report, to target the remaining records you need to purge or delete.

Additional Documentation: