Welcome to Luminate Ideas!

Please submit all product enhancement ideas below. We welcome your feedback; your ideas will be reviewed by the Product Manager that oversees the development of that part of the product on an ongoing basis and updated with its current status monthly based on our product planning process. Ideas you submit could help us shape features currently in development or grow our repository of requirements for our next big enhancement. Thank you for taking the time to share your thoughts and expertise with us.

If you believe you are experiencing a defect please contact Support.

Allow autoresponders in a blueprint to push down to child events even if disabled initially

Currently, if you build a blueprint and leave an autoresponder disabled, and then create your child events, if you later want to enable that autoresponder for all child events, you can't. It's an odd item to be unable to push down to child events since they all share the same IDs across all TRs. You aren't creating new autoresponders - you're just enabling/disabling what already exists. It's very confusing and doesn't follow the rules of other elements that are system generated for all events and have shared element IDs from parent to child, such as standard TR pages. This comes up frequently for optional autoresponders, such as the Follow Up messages or if you must launch your events before you have your incentive program (milestones) completed. You shouldn't have to enable all autoresponders, create the child events, and then disable the ones you may not use later and push the changes, just so you can have the option to enable autoresponders at a later time.