Attention: Confluence is not suitable for the storage of highly confidential data. Please ensure that any data classified as Highly Protected is stored using a more secure platform.
If you have any questions, please refer to the University's data classification guide or contact ict.askcyber@sydney.edu.au
AVE-14 Do not engage Solution Evaluation
- rommel.ngo
- Yeng Sembrano
Status | IN PROGRESS |
Owner | @rommel.ngo @jessica.wood @AlainGasquet @Yeng Sembrano @Liz Enright @Adriana Sung |
|---|---|
Contributors | @rommel.ngo @jessica.wood @Yeng Sembrano @AlainGasquet @Liz Enright |
Approved | |
Due date | Oct 14, 2022 |
Decision | NOT DECIDED |
On this page |
Problem statement
We need a way to distinguish between an individuals contact preferences which is a legal requirement to adhere to and the University of Sydney’s decision on how they want to engage or not engage with an individual.
Proposition is to build a ‘do not engage’ / ‘Communication Blockout’ check-box with associated start and end dates and a reason picklist. (e.g. under investigation, vulnerable).
These would trigger business rules on how we engage and on what type of content people should still receive SAM and similar content but we do not want to engage them for solicitation.
It would also give us a time frame to build reviews and or extend to other business areas in single CRM like students with as an example an exam blockout.
Research insights
In Speaking with Prospect Development we could have the following reasons:
Vulnerable - (which would supersede our vulnerable checkbox)
Under Investigation - this would trigger a business process to review these periodically to ensure they are moved in or out of this flag - eg flagged in media as under investigation or we have concerns around due diligence
Requires Approval - this would be a higher level flag for people who have criminal histories, illegitimate revenue sources as an example. Instead of being super specific the thought process is something like this to capture and a business process that requires these people to be approved to be included in activities.
Our Choice - often we make a deliberate choice to not contact someone, no way of determining this was our choice not the individuals and as such legally we are able to contact them in the future if circumstances change
Solution hypothesis
Currently if someone is vulnerable, example being if we have been notified they have dementia by their family and as such we don't want to solicit, but we still want to send them particular alumni communications. We would in the current practice mark them as do not solicit. This is not a flag that is explicitly followed by the Development team as there is a significant number of contacts that were marked as DNC or DNS by Development staff instead of other handlings to stop the phone program contacting them. This that we do not know if it was us or them. This opens us up to inconsistent use of the same fields.
By separating out actions decided by us eg don't engage with someone as they are under investigation this will also allow these fields to be reviewed and then removed based on dates or time frames, it also gives us an additional layer of protection, they contact us about something we can see that quickly and manage the situation accordingly, having to look through 10’s of campaigns buried in someone's contact record is not very user friendly which will also create barriers to people looking for it. We are also using alerts as a portfolio to flag these things like due diligence concern stand alone, these alerts only work at a one to one level, these flags do not stop someone from being pulled into lists as this is not a preference. I think we need to really build our own rigour and business rules to ensure we are consistent across the portfolio as we merge with other instances of salesforce.
Design options
| OPTION A: New fields  | OPTION B: Use Special Handling Campaigns | |
|---|---|---|---|
Overview | to build a ‘do not engage’ / ‘Communication Blockout’ check-box with associated start and end dates and a reason picklist. The start and end date could potentially indicate the validity of the block-out period. We can possibly also run a scheduled flow to set and unset the checkbox based on the start and end date at midnight to ensure when marketing segments their data, the blockout is checkbox is set or unset based on these start and end dates. | The purpose described for the “Do Not Engage” does not align to the activity specific Special Handling process using the object (Campaigns). In addition user profiles and permission sets plus ownership of data for Campaigns is not accessible to intended users such as the Development Officer’s do not have access to make changes to campaign members.
In addition with the future transfer of the Special Handling to a more purpose designed Preference Centre, these will not be outward facing preferences to be selected by an individual, these are handlings chosen by the University to put in place to protect both an individual and the university for a variety of reasons, As such there needs to be a clear distinction between the two. | |
Screenshot | |||
Benefits and risks | fields are easily accessible by users and possibly by marketing automation so we can build out business rules for exclusions in the future. Save us costly storage space As the purpose of this differ from the rest of the Special Handling, we think this is something that should reside in the contact object It seems inconsistent if we have to refer to additional fields to look for data that have a similar purpose as the rest of the existing special handling. we could end up with a lot of fields that we need to look out for when pulling data which pose more risk if something gets missed unless we make the reason picklist multi select, it’s only going to be one or the other. And multi select picklist might be an overkill? this field which is specifically used only for events and programs may not be scalable to be used for marketing automation in the future this can be a band-aid solution which entails rework to back-end formulas, reports and SQL scripts. Saving on storage cost may not be significant as it will also increase storage in contact object. | No need to define new fields for which in history there were only a handful of cases for which we have to use this for. Only Reason field is needed to be added to distinguish which is Contact preferred vs TAP preferred special handling. We stay consistent with where we currently store special handling. If we have to migrate them all at later stage, we migrate them just from “one place”. A report template can be created with cross filters to these special handling to minimise the difficulty in pulling the data No need to rework existing scripts that are used to pull data. So campaigns aren't really designed to manage handling preferences and this is something that will really need to change as we move to a single CRM and look at marketing automation. creates a storage issue, campaign member takes up 21% of total storage used. However I think storage will be less of an issue when we have more due to SINGL CRM and archiving (not 100% sure of this) need awareness for users to know how they are used and that they exist (to be fair it’s just going to be probably 3 more additional special handling campaign, one for each reason) | |
Criteria | Component | Need to create new component | Existing Components + new component to make it more usable |
Daniel (Architect) Endorsement | no data | Yes | |
|
|
| |
Follow up
Decision | Status | Next steps |
|---|---|---|
decided / in review / other | ||
|
|
|
Source files
Type /link to add links to design files.