AVE-37 Understand AS-IS process for Account/Contact creation
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-37 Understand AS-IS process for Account/Contact creation
The integration only creates accounts of record type “Household” of Alumni and Graduands with 1 to 1 relationship on Contact
Integration document to be shared by @Manpreet Sidhu
Integration runs once a day at night and is Mulesoft API based.
The integration does an Upsert and checks for existing data through some rules:
First it checks for Student Id
Then it tries to match (Email, First Name, Last Name, Date of Birth)
There is an in flight project where hidden date fields are added to store when certain fields are updated
Other data sources
iModule also is another integration that creates Accounts and Contacts (Swift)
Manual
SITS is a one way integration to Jarvis
there is an custom object in Jarvis which logs integration errors called “USyd Integration Errors” which is monitored by Data Stewards (i.e. Pat)
ASR also updates contacts manually either direct edit or data import
Miranda: somebody supplied updated email, changed it in Jarvis, SITS integration run again and wash out the supplied email. (Miranda can take a screenshot)
This one is SITS overwriting first party data added to the system from a alumni updating their details through a ASR campaign. It's probably not students having a donor duplicate record but older alumni with donor duplicate record.
For Major Donors, accounts and contacts have already been created
Prospect Journey
The only time GA will create Accounts and Contacts is with a an unexpected donor.
Forms are created in iModules (Giving Platform) where people will donate. Integration will pick up iModule files and create the gift and match an account. If no Account is matched, system will create a Lead and assign the Gift to a generic account. Batch source of data is set to “Online Giving (iModules)
IModules will send First Name, Last Name, and Email. As well as Billing Phone, and Address
and Once a Lead is created, GA team is going to try to match the contact on a Lead with existing Account/Contact. If none found, they will convert the lead to account and contact. The gift is then linked to the newly created account through the Batch Item - Lead Linkage.
Seymour Center sends a file every month to GA team which they will process and create batch items for through. GA team will create a case to Yeng’s team to do matching for the contacts.
Perfect Match is First Name, Last Name, Email
then match by address
GA will review the Match done by Yeng’s team and if an account needs to be created, Yeng’s team will do so through data loader
Yeng’s team will create the Batch.
Manual matching of contacts
Missing data such as email. They go back to the originator such as Major Donors and they need to go back to Prospect Development
if a donor is not alumni they might need to create the account/contact - they use Account Create
Often arise from individual research, could be from a list of people attending an event.
Update if the account is an active prospect and update prospect status. Put in rating, add in relationship.
when deciding who will be the primary contact on a household, one of the criteria is whoever did the degree will be set as the primary contact.
Ratings are entered by prospect development team. They also use over all account rating. One for each rating type is active at a time.
Liz/Steven: Account type is not clear why it is required but not in the Account creation screen. They are not clear what is the use of this field.
Liz: No contact on an account specially on corporations that were migrated from Advance where they were attached dummy contacts to when migrated to Jarvis. With no primary contact, receipting fails.
Liz: Clarity on the use of Primary and Secondary Contact on the account.
Steven/Jess: if we can link soft credits directly to contacts directly
Steven : parent child account usage/representation in Jarvis needs to be fleshed out. Potentially if we can report on the connectivity and look for potential contacts that works in a particular organization that we are looking to solicit from. Say for example a contact works for a company A (where an employment record exist) which is a subsidiary of another company B, we need to be able to link this contact when we are looking for contacts associated with Company B. Note that contact is linked to company B via employment record and may not have a contact to account relationship.
vast majority of alumni are created through SITS when they graduate
< 2002 records are problematic due to lack of complete details such as email, mobile, etc.
around 2010 - 2016 they were heavy on buying list rentals where a lot of legacy non alumni donors came in.
Go out with event registrations, opportunities to b mentors, various communications (surveys, etc.), have forms where people can update their details.
Faculty run alumni engagements, ASR share outward data to faculties.
External engagement share new people (interested in philanthropy). approximately 30 people a year.
Creation of staff contact (specially academics) playing active or supporting role into an opportunity (major giving). This gives us insights on which staff are actively participating in fundraising activities.
Most special handling are sitting on the contact(do not call, do not contact, do not mail). Unsubscribes are added to exclusion campaigns (about 60). If it is a swift email, the unscubribe are stored in swift and they are bought back into the system(to validate this)(No event invitation, no donor event invitation, no donor communication). some are not connected(no quizzes, no spring appeal, may tax only).
RTS process. managed manually in some cases. Mail house produce file for RTS, coming out of SAM (print magazine). Marked on the contact. they might be looking for a new mail house to supply SAM. This goes out twice a year. Sam extra, Monthly e newsletter.
Friend, is excluded from community giving campaigns/activities. because they don't necessarily know that they are in our system. Definition of friend
We do have lots of external research institutes that come into play with donor space (macula), they are exclusive domain of that area. People who give exclusively to domain area
we get request from faculties of what data they want to see. Can be based on education, interests, level of giving, or combinations of factors. We get help of Alain’s team. Simplier request by ASR. More complex with Miranda, and if more complex that than goes to Alain’s team.
Swift is only handling half of Alum comms. We also have signature events for more high profile events which is sent out through central events office which is using Swoogo Then usually are just returned as spreadsheets.
Miranda: Alumni’s who update their details 20 years later, matching process becomes quite a bit more manual (they have form in website for alumni to update their details). The “Bot” does the matching but when exception arise, that is where Yeng’s team process the data manually. These alumni do not really remember their student ids. Graduates who don’t have email (half of the alumni). The form is Swift Digital form that gets dump into a folder where the “Bot” picks them up and process them.
Miranda: alumni are providing work emails and there is no clear instruction/process whether they would use them because they are new even though there exist personal email? For contacts with multiple emails they are constantly shifting where they are receiving things around. Limited ways to know where (with the exception of the contact history object) data comes in from (SITS or Provided). No transparency where data is coming from. We don't have a established rule of what should be the preferred contact information.
Miranda: contacts are being created as donor separate from their alumni record, due to reason that alumni details are so out of date and updates are coming through iModule it becomes impossible to match them.
Miranda: Matching process has become problematic. Specially on getting data up to date for records of older alumni. There are different version of what people consider a match through time. Lots of records do not have emails, they only have the degree information. Clear matching definition.
Liz: Sensis data purchased during 2019-2020. Overwrote data with incorrect ones. and people were missing out on communication
Miranda: some data are overwritten, there is no clarity as to whether the data is new detail that someone has actively given that should not be overwritten. Not being able to tell how old the data is, where it came from. Not having control over integration overwriting data.
Miranda: when data are shared outward to faculties we don't usually get data back such as unsubscribes. When alumni update their details/unsubscribe through faculties. Faculties have their own marketing platforms(swift digital, HQ?, Hubspot, etc.).
Miranda: example Law Architecture School mailing list (newsletter). People sigh up for newsletter through university website. It is unclear as to a privacy statement exist for such. this is a problem for reabsorbing information. we can’t benefit from other parts of the university interaction with the same group of people. (top pain point)
Miranda: quite challenging to manage exclusions campaign. One needs to be familiar on the exclusion campaigns.
Miranda/Liz: a potential opportunity to automate if possible manual update of RTS
Miranda: Contact types, some legacy ones are super confusing (i.e. alumni affiliate). Definition for Friend. clarity on what does contact types do in terms of communication preferences. And how can we know our legal ability to contact people (decision to be made by OGC) on what channels. Tidy up contact types list. Short award courses but not degrees completion are not clear if they should be alumni or not. Another example is with people who studied in an agriculture institute in Orange and that institution has been absorbed as part of USYD (possibly why there is alumni affiliate contact type). Ancient Pharmacy degree, where it used to be not part of USYD.
Miranda: definition of “Friend” contact is contactable or not
Alain: reports that take into consideration activity based on faculty, giving, targeting people, we needed combined way.
Alain: we need account type and contact type to be consistent. we don't wat a solicitor within a household account for example. we can’t target the right people
Alain: rules of engagement, we need to facilitate in a way to filtering of people to generate list of prospects for engagement on mass scale. Building datasets with all of these rules. where you can also add filters as need be. i.e. user do not have the error of creating campaign without filtering out do not campaign contacts. Or maybe you want to exclude any kind of VIP who needs exclusive engagement and we don't want to send them random emails. We want to target the ight people but we are limited by the data sets available and to a degree not reliable.
Alain: The giving summaries by affinaquest are a bit misleading and the contents can be easily misinterpreted. Specially for highest donors, it is a problem to have misleading information. for example we have donors who give out millions but when you look into the account it does not show that.
Miranda: on community giving, we really just want to focus on legal credit side for things as opposed to high end donors.
Keri : Unclear process to relate contacts and accounts when working on accounts/Contacts that’s to do with Trusts/Business. Unclear who’s the primary apart from the receipting care of(dummy field migrated form advance) on a Trust account
Keri : Donor relation events and we are inviting Trusts but they don’t have a contact and there is no way to include them when we use contact to include in an event.
Ana : there is no standard process to refer to and that system is not used the same way through the portfolio. We need an understanding and SOP when to link via employment and link them in relationships. Names on accounts and contacts are confusing and which one is used for which needs to be standardized.
Monica : when a contact is already linked to another account, they end up having to use or retain the dummy contact to an organization for receipting to work.
Monica : streamline the screens, a lot of values are very similar. Lock down unused fields and force users down a path to maintain our data quality.
Monica: we need to figure out what relationships we want to capture and the naming conventions specially where one party of household might be deceased (Because it doesn't look good if you're going to be sending out invitations to you know Mrs Smith and Mr Smith deceased)
Monica : figure out how we’re dealing with event invitations and be consistent in how we are updating contact info and all reports that we use are aligned with those fields. As an example we need to ensure that receipts are being sent to the most appropriate address, and that that field is also the field that all the users are updating..
Monica : receipting care of should be migrated into proper contacts
Monica: if we could have a system where we can have some flexibility on where we send our correspondence and not tied to just the primary or secondary contacts (i.e. receipt needs to go to a particular person at a particular address). Correspondence such as pledge reminders, event invitations, solicitations)
Monica : we need to direct users in creating account and put validations to use the correct one for particular type of accounts being created (Account Create Utility). When adding new contact to an account, they are not necessarily aware of the legal credit and recognition credit percentages which causes issues down the track.
Monica : new accounts come in as leads and converted to new accounts/contact and there is an issue where they are automatically being created a s alumni
Monica: need to review contact type and secondary contact type to reflect relationship with the university. We also need to iron out what is on contact type and what is on secondary contact type (i.e. alumni and donor respectively). Have a clear guidelines on how we use them.
Alain : we need the system to control the setting of contact type specially with one CRM coming in. If new contact types are added, we need to make sure the hierarchy are put in place and are being set correctly.
Monica: we need to pay a lot of attention to names that could lead to duplicate records (i.e. Jennifer as Jenny). Use preferred name and we need to define what name we use for the correspondence (check if there is flexibility on what name to use). For example Benjamin Newton
Jess : If we have sub contact types are we better storing that elsewhere that is still functional and delivers on our business processes as well. (in consideration of single CRM, that we don’t add unnecessary complexity)
Monica: creating a contact and assigning them as the primary and secondary contact or two different processes, what will often find is that they are contacts on the account but they haven't actually been sent set as a primary or secondary contact.
Monica: we are using receipting care of and if there isn’t one we use credited contact.
Monica: activity reports in contact and account level, can we define this process more specifically. (Jess’s team use Activity rather than activity reports)
Jess: if a contact is updated (i.e. married) do we have a workflow that updates the account name as well? Issues arise for example when one updates contact and assumed that it updates the account as well. (applies to join, separate and decease as well)
Monica : validate on accounts created for corporate contacts. Business rule on contacts that needs to be created as household accounts vis a vis their organization contact. (one of the things you could look at was any household types that maybe there's specified that contact type is a corporate contact or foundation contact or something that is not individual, education, student id if graduand)
Monica : we need to ensure the data structure is set up correctly so that we may for example run reports accurately such as to be able to compare lifetime giving of the person that is deceased versus what has come in through their bequest.
Monica: we need to be clear on the validation around how we are connecting things based on their types (i.e. estate, organization, household)
sent through email:
Harpeet : When creating Accounts and Contacts there’s often a duplication of data entry items because it is common for the deceased not to exist in our system. It is common I need to added addresses and names multiple times – once for the estate, once for the contact and then for the account (now I simply open a contact and then add it to the estate). There’s a duplication of tasks here. I’m not sure if it can be rectified
Harepeet: The phone contact details and emails for the contacts don’t allow for home, work, and mobile numbers to be added, nor for the accounts
Harpeet: When people die and they have a joint account with their spouse, the account is marked deceased. I don’t know how, but somehow the contact has to be ‘broken’ into two separate people – as Monica said, it’s a bit uncomfortable sending a letter to a living person if their spouse is deceased and the letter lists them both as deceased
Action items
@rommel.ngo To get from @Yeng Sembrano Hierarchy of Contact Type for which will be used as “primary” contact type
Contact Type
Priority
Contact Type
Priority
Alumni
1
Alumni Affiliate
2
Corporate Contact
Donor
8
Executor
Former Staff
7
Foundation Contact
Friend
22
Graduand
4
Parent of Student - Alumni
9
Patient
Solicitor
Staff
6
Student
5
@steven.barwald to provide list of wish list. What sort of information is needed to be seen in one view. (Degree, engagement, accolades)
@AlainGasquet to provide a list of wish list.
Decisions
OGC - need to be consulted and have a guideline on contacts who are tagged as Alumni Affiliate. We need to tell them what Alumni affiliate is made out of
