Stumbled over another C code: C003

sample key "Name" in triggers.pitch has been changed/removed (C003) 

The URL leads just to the document without the appropriate anchor.

It looks like these are merely informative to summarize changes to ease review of changes. But would be nice to learn more about the consequences of each of these changes.

@toktok sorry about that! The docs are written, but apparently not deployed. the CXXX checks are all very similar and their docs are as follows:

C001:
> Try To Avoid Hiding/Removing Public Triggers/Searches/Creates

> During promotion, we compare features of your currently public version with your soon-to-be-public version.

> When you hide/remove a trigger in a new version, Zap Templates that use that trigger become invalid. Try to avoid this when you can. The same applies for searches and creates.

C003:
> …

> …

> When you change/remove the `key` property of an item in your `sample`, Zap Templates that use that field become invalid. Try to avoid this when you can.

@xavdid Thanks for keeping me in the loop.

C001: We’ve identified early created triggers (and creates) with wrong nouns. That means keys and file-names will change. Any ideas how to mitigate that? I can understand it’s breaking, not so sure if the “key is key”, but from my end it looks like it. Is there any aliasing available perhaps? In any case we’ll tear down the wrong structure and put it under correct names. So from your comment I’d expect that things will break for existing Zaps if they migrate the version.

C003: We’ve identified bogus sample data and removed it. This especially was for keys and these were even without labels. For fields (I’ll just call them this way), is there some kind of fall-back, so that if the key changes but the label stays the same, that the behaviour would be preserved as long as (e.g. as a fall-back) a same named label is found? We tested migrations and it looks like so, but some more information would be nice to know (this is especially about input and output fields. The integration I’m concerned about is with many dynamic fields, and we’ve made the keys much more stable so “client side” renaming fields does not affect the keys any longer, only the labels)

It’s worth noting that the Cxxx checks concern Zap Templates specifically. When you promote a new version that fails a C check, some ZTs may be in a bad state. You can work with the partnerships team to fix those. 

As far as live zaps, you’re safe to promote your new version, but may not be able to automatically migrate users between them. That’s ok - by design, it’s fine to leave existing zaps on older versions. Really the only thing that will break a zap is changes to the “key” of a trigger/serach/action or input field (or a coding mistake). Past that, Cxxx checks won’t necessarily affect zaps.

C001: If you’re talking about the actual “noun” field, that’s not used by actual zaps. If you’ve changed keys, you probably can’t migrate zaps.

C003: Sample data doesn’t affect zaps that have already been created. Labels also don’t matter after zap creation (only “key” matters). 

Based on the above, it sounds like you’re good to go, but we’d need to look at your actual changes to be sure. Feel free to write into partners@zapier.com with your app id if you’d like us to take a closer look.

The check docs have been updated: https://platform.zapier.com/docs/integration-checks-reference#c001---try-to-avoid-hidingremoving-public-triggerssearchescreates

Thanks for the reminder on the Templates and all the other feedback. Very helpful!