Using the Right to be Forgotten (RTBF) in OpenCRM has two parts. The first is how you mark a record as having made a RTBF request and the second is the workflow (or actions) that take place after the fact.

Extra Information

Before you start, there are some additional FAQs and information you might find useful as part of your preparations.

• How to write data retention rules to ensure attachments are removed from records?
• What does it mean to delete something in OpenCRM?
• General GDPR information page

Making a Right to be Forgotten Request

When it comes to carrying out your data retention policies on RTBF requests, you can mark these records however you think will work best for your business.

But, as a way to help you, we've written a system field that will help you flag these records and will carry out some additional functions in your database with regard to your back-ups.

Essentially the field works like this:

1. You navigate to the Lead, Contact, or Company who is making the request.

2. In the "Contact Restrictions" block there is a field called "Right to be forgotten" 

    a. Important: this field is only available, by default, to users with the "administrator" profile. It is a very powerful feature, so consider carefully if you want to open this up to other users. 

3. When you tick the box, you will get a popup telling you some important information about the way this feature works and asking you to confirm that you have read it

    a. Important: If you click cancel or enter the wrong value, the record will not be marked as RTBF.

4. Once you type in "YesRTBF" you will need to SAVE the record and then this will kick off your data retention policies regarding all RTBF requests (see below for information on setting up your rules).

    a. If you CANCEL from the record the Right to be Forgotten field will not be saved.

5. The system automatically logs the date the RTBF field was set and the user who set it.  If you untick the "Right to be Forgotten" tickbox, the date remains on the record to show the history of your interaction with it--if you decide to run your RTBF rules using this date field, we would advise that you ALSO use the tickbox to ensure you don't run any rules against a record that has changed their minds. 

    a. The system also logs any change in the audit log.

6. The RTBF field is strongly recommended as your means for triggering RTBF requests for your business.

It provides a standard and audited means for checking these requests and has back up measures to reduce the chance that someone subject to a RTBF request could be later restored in error.

In addition to the auditing described all requests are logged in an isolated table within your own systems database and also in a separate central database. This logging ensures that should a record that was subject to a RTBF be somehow later restored, for example via a system backup, the record will be reflagged as having had a RTBF request thus triggering your RTBF rules, provided that as we recommend they function from the RTBF field.

Using the Right to be Forgotten Workflow/Rules

1. To set up your Right to be Forgotten rules, go to Settings and click to expand the "Workflow" link. This will give you a link to our Right to be Forgotten rules.

2. You will then see a popup asking you to confirm that you understand the serious nature of the actions you will be performing against your data.

3. Once you have confirmed that you understand the risk, you will be taken to the main Right to be Forgotten page, where you can:

    a. Create new rules (click the New button at the top)

    b. View which rules are currently active (Yes/No text on the right side of the table)

    c. Edit existing rules (click the "Edit" link on the right side)

    d. Duplicate existing rules (link on the right side)

    e. Delete existing rules (also a link on the right side)

    f. Audit existing rules (this will show you who has edited your rules and what they have done)

4.  When you are creating a new rule, the page you will see will look like this (there are three keys areas to know):

Section 1: Description

This top section is where you:

1. Pick which module you'd like to run your rule against
2. Name your rule - try and give it something that will make sense later
3. Describe your rule - explain exactly what it is going to do, you don't want to always have to edit a rule to remember what it is doing
4. Set whether it is Active - it is probably a good idea to leave your Right to be Forgotten as NOT ACTIVE (unticked) until you are absolutely done drafting them...you don't want these rules to run against your data until you are absolutely ready.

Section 2: Conditions

This section is where you describe the criteria this rule will use to identify the records that will be subject to your right to be forgotten rules. 

It works by you picking a field and setting some parameters. In this case, you will probably be relying on the "Right to be Forgotten" field, but you might also want to add date fields to record the actual date of the request or a secondary approval field (for example). 

You have two options when setting up these conditions:

1. Match ANY of the conditions - Think of this as an "or" option. So in the example below, your workflow will be run against Contacts who have Do not Email ticked OR those with the job title "Former Employee" OR both
2. Match ALL of the conditions - This is the "and" option. It will only run if a Contact has both Do Not Email ticked AND the job title "Former Employee"

In the example screenshotted in the previous section, we have decided to use the RTBF tickbox field AND a date field. This means that both conditions have to be met before the actions below will be run.

A note on filtering on a date field: The before filter means that you will be targeting both a specific day and everything before that date. The positive and negative numbers are the number of days before or after the current date. So for example: 

Returned Date	Filter
(In all of the below examples, we are going to assume that the "current date" is 3 January 2019 and give you the date (or range of dates) that the selected filter would return.)
1 Jan 1970 to 1 Jan 2019
1 Jan 1970 to 6 Jan 2019

Section 3: Actions

In our example, we've decided to add a Warning to the Lead and let our Data Protection Officer know what has happened. 

Remember: you can set up several rules to run against the same record over different periods of time. So this example has just a couple actions being carried out on the first day, but maybe after 3 additional days, the record will have it's fields cleared. 

You have numerous of actions to chose from here:

• Update Self: This one is pretty straightforward, if a record meets the criteria you set in section 2, it will make a change to itself.
• Create New...: This action allows you to create a new record when your conditions are met.
• Update Linked...: Just like the "Update Self" option, this will allow you to update records linked to any record that meets your criteria.
  • As an example, you might want to update all pending Activities to be marked as Cancelled (as you no longer think it is necessary)
  • This will affect all records of the module you've selected that are linked to all records that meet your conditions.
• Send Notification: Pretty much what it says on the tin, this action will allow you to send a notification to someone (you can include users or email addresses in this field)
  • In our example, we want to alert the DPO that a RTBF request has been made.
• Add Warning: This action will add a warning to your record. This is a very useful one for Data Retention Rules because you can use it to highlight where the record is within your policies.
  • In our example, we want to make sure everyone knows what has happened with this record, just to make sure they don't get in touch.
  • Tip: if you add a "code" to this warning, you can then use the next action (Remove Warning) to do just that.
• Remove Warning: If you have added a code to your warnings, you can use this action to remove them.
• Clear Selected Fields: This action will let you pick our certain fields to set as blank when the record meets the criteria.
  • This is a really useful one for the first stages of RTBF as you could, for example, clear out selected personal details from your records: email addresses or birthdates for example.
  • Warning: The OpenCRM support team cannot undo this action once it is done, so make absolutely sure you want to do this to all records that meet the conditions you've set out.
• Clear All Fields: Just like with clearing selected fields, you can obliterate all fields on a record, leaving it blank. 
  • This is one you will probably use at the latest stages of your right to be forgotten rules. 
  • Warning: The OpenCRM support team cannot undo this action once it is done, so make absolutely sure you want to do this to all records that meet the conditions you've set out.
• Delete Self: As it says on the tin, once a record meets your conditions, it will be deleted.
  • Important: When a record is deleted, that record and all of its details will still exist in the database. It can be included in Reports or Custom View by an administrator, but will not show in the system or exports unless specifically included. It would be included in a backup or any requested database copy. The record can be restored using the "Recycle Bin” feature in Settings.
• Delete Linked: Again, just like what it sounds like, all the records from a particular module that are linked to the record that has met your criteria will be deleted.
  • Important: When a record is deleted, that record and all of its details will still exist in the database. It can be included in Reports or Custom View by an administrator, but will not show in the system or exports unless specifically included. It would be included in a backup or any requested database copy. The record can be restored using the "Recycle Bin” feature in Settings.
• Remove Links: This will unlink all records from the module you select from the record that meets your conditions. 
  • For example, any Emails you had linked to your RTBF Lead would still exist in OpenCRM, but would not be linked to it.
• Update Linked - Clear Selected Fields: Just like as the "Clear Selected Fields" above, but gives you the option to clear fields from records that are linked to the ones meeting your data retention policy.
  • For example, you might want to clear the email addresses of all Contacts linked to a Company that makes a RTBF request to prevent accidentally sending them marketing emails.
  • Warning: The OpenCRM support team cannot undo this action once it is done, so make absolutely sure you want to do this to all records that meet the conditions you've set out.
• Update Linked - Clear All Fields: Again, just like above, this will clear all the fields on all the records in the module you've selected that are linked to any record that meets your conditions.
  • We refer to this option as the "obliterate" action as it leaves your records totally blank.
  • Warning: The OpenCRM support team cannot undo this action once it is done, so make absolutely sure you want to do this to all records that meet the conditions you've set out.
• Wipe Audit Log: Another one for the end of your right to be forgotten policies. If you are recording all changes to your records in the audit log, it will be full of a fair amount of personal data (previous email addresses, names, etc.). This wipes the log for the selected record and leaves a note saying why the log is now blank.
• Update Linked - Wipe Audit Log: As above, but will wipe the audit logs of the linked records of a particular module.

4. If/When you mark your rule as "Active", clicking the Save button will trigger the following popup.

Once you click OK, you will be taken to a screen that will display the primary records in your system that will be affected by the workflow.

The fields that match your rule will be displayed, you can also click the link on the right to view a particular record.

Once you click the Activate Rule button, your rule will be marked as active and will start running.

Clicking to Edit Rule will take you back to the previous screen.

You cannot set a rule as active without running this test.

(You can test any rule at any time by clicking the "test rule" link on the right of the workflow home screen)

The Importance of Duplicating

Again, just like editing a rule, you can use the "Duplicate" link to make a copy of your data retention rule. This is a great way to build up the phases of your right to be forgotten polices. 

In our above example, you might want to have the DPO check and confirm the request, filling in the date they have done so. You could then use this date to add an additional condition for the second phase of your RTBF policy. 

Copying information from one module to another

You can use workflow to inherit information that could not otherwise be mapped from one module to another.

An example of this would be copying the Assigned to from a Company record onto linked Projects.

Important: You can only copy data from the originating record, not another dependent record.

In the example below, the workflow is set up to copy the Assigned to from the Company onto all linked Projects, while setting the Assigned to on linked Contracts to a particular user.

The first action (highlighted in red) shows:

1. Circle: the field being populated on the linked Project
2. Arrow: which action I want to take, for this linked Project I have selected Inherit
   1. Once you select inherit, you'll be able to choose a field from the originating record.
   2. It does not have to be the same field (i.e. Assigned to). 
3. Rectangle: the field being copied from the originating record (which is a Company with type = Customer in this case)

The second action (highlighted in blue) shows the same:

1. Circle: the field being populated on the linked Contract
2. Arrow: the action I want to take, in this case I want a set value on ALL linked Contracts, regardless of who the Company is assigned to
   1. When I select "Set Value" this pulls the information from the module being updated, not the originating module
3. Rectangle: my selected value 

What about Back ups?

Now this is the really great thing about using the "Right to be forgotten" tickbox on your Leads, Contacts, and/or Company records. If a record has this tickbox ticked and you have to restore your database from a back, OpenCRM will re-run that record through your RTBF rules before restoring that backup.

This means that the data will not go into your live system even if the backup pre-dates the RTBF request.