Skip Navigation
Report Based Data Lifecycle Policies
Answer ID 11920   |   Last Review Date 07/29/2021

How do I create a report based data lifecycle policy?


Data Lifecycle Policy

Browser User Interface (BUI), Oracle B2C Service (OSvC)



A report based policy is intended to provide some additional flexibility regarding what records are tagged for Data Lifecycle Management. Compared to a template based policy, a report based policy lets you select a standard or custom report to determine which records the policy will apply to rather than needing to adhere to a filter template. Report based policies are available in versions 20C and above. For information specific to template based policies please review Answer ID: 15038 Creating a Data Lifecycle Policy for a standard object.
Only records that match the report's filter criteria will be flagged by the policy, so you can create policies that target very specific sets of records. Since records that match your report's filter values will be removed, it is important to know what data set is returned prior to executing any policies. In order to create report based policies you will need to follow the below steps:
  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 it it doesn't and you will need to select a different report. Otherwise, the selected report's tables and filters display.
  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: