Use related contact for email and phone (alternate approach)

[deb761]

@atlasjen My thought is we pick one of these approaches for issue 471.

Critical Changes

Changes

Create contact field to replace NPSP's preferred email field that sets Email and Phone off the contact's values or a related contact's values.

Issues Closed

471

[atlasjen]

I am worried the way this is implemented might be competing with NPSP workflow rules and that could cause some unpredictable behavior. You are effectively recreating the logic of preferred email and preferred phone. and maybe that is fine, but what about just using those and instead having a way to populate 2 custom fields if the relationship type of Guardian is set? Or do you think we are better off using code vs the Workflow Rule objects?

It turns out we have a lot of workflow rules active by default in prod. https://atlasassistancedogs.lightning.force.com/lightning/setup/WorkflowRules/home

we can add a new reciprocal relationship

It actually looks like we might be able to use workflow rules on "Relationship" to modify "Contact".

So some options

1. In workflow rules, implement what you have that sets phone or email to whatever is in related contact phone/email if relationshiptype =guardian .

2. add "guardian" as a picklist type for preferred phone and email and have it point to custom fields Contact.GuardianEmail Contact.GuardianPhone

and we can update the workflow rules to add logic about setting email or phone to what is in guardian if it is set in preferred email/phone and we use your code to populate those fields

3. we use the Contact Preference dropdown you added or check box and if it is set to guardian, your code grabs the related contact info (if type=guardian) and populates phone and email.

one risk in approach 2 or 3 is if the guardian related contact phone or email is changed, it will not roll back up. I think it might roll up in option 1.

thoughts? Sorry. I didn't actually realize these workflow rules existed until i started trying to search on this today.

[atlasjen]

Decided we are going to use this approach and deactivate the various NPSP workflow rules.

What we still need to add:

• if contact email or phone changes-> need to check their related contacts and see if Contact At is set to this contact. if so update email and phone of related contact.

• Add in equiv of these workflow rules for Contact Home and Alternate only (not changing across contact/related contact) and add in NULL/empty checks:

  • If the standard Email field is newly entered or changed AND the Preferred Email picklist is set to Personal or Home THEN Salesforce will fill in the Personal Email field with the email address entered in the standard Email field.
  • If the standard Email field is newly entered or changed AND the Preferred Email picklist is set to Alternate THEN Salesforce will fill in the Alternate Email field with the email address entered in the standard Email field.
  • If the standard Phone field is newly entered or changed AND the Preferred Phone picklist is set to Home THEN Salesforce will fill in the Home Phone field with the phone number entered in the standard Phone field
  • If the standard Phone field is newly entered or changed AND the Preferred Phone picklist is set to Other THEN Salesforce will fill in the Other Phone field with the phone number entered in the standard Phone field.

[atlasjen]

I tried this in a new scratch org and am seeing these errors

[atlasjen]

Did a bunch of testing. Looking pretty good.

1. Can you set "home" as the default "Contact At" so when we create a new contact the trigger to populate preferred email?

2. I tried a case where there was no related contact yet. i set Contact At as "guardian", i made sure the relationship type was there. i then created the Guardian related contact. I then went back to the contact and refreshed but the related contact's info didn't show. I edited the related contact and then their info appeared in the Contact. We should make sure that if the contact at is a related one (something other than home or alternate) that we are pulling their info even if it wasn't updated.

I tested a bunch of other cases w/ alternate and home and that all seemed to work as expected.

[deb761]

Your second case is one I thought of, but didn't see that I could cover. Maybe if I add a trigger on create Relationship.

[atlasjen]

Your second case is one I thought of, but didn't see that I could cover. Maybe if I add a trigger on create Relationship.

I'm wondering about this flow- a contact is viewed. and then via trigger

• check to see what is in "Contact At"
• see if need to update the email/phone?

not sure how much overhead that is. If it is editing the Alternate or Home, that will be taken care of while they are already on the contact page, so in theory shouldn't be out of date.. though those could get set from form assembly imports, so we would want to make sure we aren't relying on clicks on the page layout to set email/phone. if we think that is safe, then it would really just be checking if it is something other than home or alternate and looking to see if a related record of that type exists.

[atlasjen]

post discussion, agreeing business process will require that related contact of "guardian" exists before setting Contact At to "guardian" (or any other related value). TODO

• update tool tip on Contact At
• update default to be Home merge it.