Looks to me like a breaking change was made from 1.0.3 to 1.0.4. If there is a create action called create_infopage in 1.0.3 that isn’t there in 1.0.4, any Zap that uses that action is going to break if you switched it over to 1.0.4. To illustrate what’s going on, imagine in your code, someone renames a function in a library you use - all your references to that function are going to error with an undefined reference of some sort. Same thing here. 

Two options.

1. Just leave everyone on 1.0.3 and don’t try and migrate. New users from this point on can use 1.0.4 and you’ll have two code streams to keep in mind. Rename 1.0.4 to 2.0.0 to reflect the breaking nature of the differences if you do this. Eventually you can deprecate 1.0.3 forcing user to reset up their Zaps. Use this feature sparingly, only when you really need it. It’s not a great experience for users to have to do often.
2. Leave the create_infopage in 1.0.4, but mark it hidden. Existing references to it still work. New users won’t see it. Usage of it will decrease over time. Creates a little bit of kruft to clean up the next time you do decide to make an actual breaking change, requiring users to reconfigure their Zap steps. 

Pros and cons to each approach. We’re talking a lot about how we can make this better for developers and for users, but for now those are the ways to go.