We would like the ability to set the Email Type and Primary Email flag in Altru only if a new constituent is being added to Altru in an OIC formula. As it stands now, we have those fields unmapped because we don't want to risk OIC changing a record's existing Email Type or Primary Email Address. This means we have to go into any new records created by the formula and manually set the Email Type and Primary Email flag.
Is this need limited to Email-related fields or do you have any other examples of fields that you would only populate on new records? For example, a specific constituent code or solicit code?
Most relevant to us would be Address fields. In MC > AL formulas we'd like to be able to add an Address that is just a ZIP code to new records, but not to existing Altru records.
Not relevant to us but possibly relevant to other orgs would be constituent code and solicit code, as you mentioned. Of course, the formula can already be set to prevent duplicate constituent or solicit codes from being added to existing records, so limiting the appending of the code itself may not be as important as making sure the Date From or Start Date doesn't get overwritten on the Altru side if the constituent/solicit code already exists there. (See my "Map attribute data only for new records" idea.)
Is there any word on whether this idea will be implemented anytime soon? We are pushing our e-newsletter signups more now due to the need to communicate about pandemic-related cancellations and as our number of new signups increases, so will our need for a feature like this. Thanks!
Thanks for reaching out again! We are working through a few ideas how on how to manage different updates for new vs existing records within formula settings, but it will not be out in time for this immediate need. However, you could try this as a temporary workaround for now:
- Create a copy of the formula that is set up with the additional fields you want for your new records. Both formulas can be set to run on a similar schedule, or you can pause them and just use the "Run Once" option to retrieve records on-demand.
- Between the two copies, make sure your Triage rules are set correctly to give you the ability to discard the "undesired" records in each. For example, in the "Existing Records" formula, send new records to Needs Attention and then delete them. In the "New Records" formula, send 1:1 and 1:Many matches to Needs Attention and delete them (since they're already covered in the other formula). Remember, there's an option in the Integrations/Formulas page to "Clear Queue," which is an easy way to delete remaining record updates across all buckets in that formula after you've sent the records you wanted.
As always, we recommend testing with a small subset of records to make sure you've configured everything correctly, but hopefully this works as a temporary measure for responding to the pandemic. When we start testing permanent solutions to this issue, we'll make sure to invite you to participate.
Senior Product Manager | Omatic Software