Closed deb761 closed 1 year ago
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
In workflow rules, implement what you have that sets phone or email to whatever is in related contact phone/email if relationshiptype =guardian .
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
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.
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:
I tried this in a new scratch org and am seeing these errors
Did a bunch of testing. Looking pretty good.
Can you set "home" as the default "Contact At" so when we create a new contact the trigger to populate preferred email?
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.
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.
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
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.
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
@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