Program name changed but Triggers not updated. Expected behavior?

[Gerard_van_den_]

I changed a number of programs this morning assuming that any references in triggers elsewhere would follow. I noticed they didn't though. Is this a bug or the way the system works?

'Person is Created' Trigger:

The second line: 'Form Name is not' contained the old names of my programs, and hence didn't exclude them after the rename action.

Anybody bumped into this before?

[Paul_Johnson]

Hey Gerard,

My guess would be it still is working just fine. have you attempted testing the trigger campaign? I would bet it would still work and the naming is simply a lag. Let me know!

[Dan_Stevens_]

In this case, it will not work fine.  The program values here will need to be updated manually per my response below. 

[SanfordWhiteman]

Strings in matching rules aren't continually synchronized with asset names (note this wouldn't be feasible given that multiple programs can have the same name over the lifetime of your database, and partial matches are completely un-sync-able).

While some program prefixes are adjusted during a clone operation, you can't rely on this working for all rules, nor after the program is cloned.

[Dan_Stevens_ · Accepted solution]

There are some instances where this will not update when you change the name of the program - and you will need to MANUALLY update these values (otherwise, your smart campaigns will not run properly).   This will often occur when the value is contained in a custom field and/or when the field doesn't solely (and only) contain PROGRAM values.  For example, when the value is included in these fields, they will always take on the current program name:

• Member of Program ("program" is xyz)
• Change Program Status ("program" is xyz)

Here's an example where the program name always gets updated - for those program values on the left - but not updated for any of the custom field values on the right (and therefore, we always must edit those values on the right after we clone the template to a production program):

The trigger you included in your example doesn't contain any "program" fields (even though they will accept names of program) - and therefore will not update when you make changes to the program name (or clone to another program).

[Gerard_van_den_]

Thanks Dan, although not ideal it does make sense they built it this way. It's certainly a wake-up call for me to pay double attention when renaming programs / campaigns and ideally I shouldn't do so at all. It's impossible to see where these values might be used, so it requires knowledge of all moving parts in the system, and it's easy to overlook something.

[SanfordWhiteman]

This is one reason that even the best-maintained instances still have manual procedures to follow.

(You can't fully avoid this area just by not renaming programs/campaigns, because cloning from a template is still a great practice.)

[Gerard_van_den_]

Certainly true. Where I went wrong is that I didn't expect my program rename to cause these side effects, whereas when cloning a program you kind of know you have to run through it to set some nuts and bolts right.

Thanks to all for your feedback.

[SanfordWhiteman]

P.S. I didn't mean you should've already had a proc in place, just that it's something to embrace rather than try to avoid since you'll always run into it.