Subscribe Block

Question

0

Subscribe Block

Andrew Metz posted 6 Years Ago

Has anyone had any success using the Subscribe block when someone is not logged in? I would like an online form/block where people can subscribe to different communication lists without being logged in, with a name/email form entry instead. This way newcomers or members who don't log in (+50%) of our church can subscribe/update preferences.

Thanks!

Shawn Ross · Answer 1 · 2018-03-15T12:07-07:00

0

Shawn Ross replied 6 Years Ago

TL;DR The block assumes the person is logged in because it's very messy otherwise to set a 'preference'

Andrew, the block is written to assume there is some kind of method to determine 'who' is arriving at the page and interacting contextually with the block.

In your use case, how would Rock know what to display to someone that it doesn't know who is?

Something to consider: if someone clicks on an unsubscribe/preferences link that was sent to them via email (from Rock), it will tokenize their link, and Rock would then know that it's them (showing the appropriate choices).

https://www.rockrms.com/Rock/BookContent/8/116#settingsubscriptionpreferences

One option would be secure (require login) a special version of the Communications Preferences the page. If you also integrate Social login options (FB, Twitter, Google), you would at worst create some duplicates your team needs to clean up

If you outline your use case some more, you may get some more ideas and insight to accomplish the same goal using a combination of tools available in Rock

Edit Answer

TL;DR The block assumes the person is logged in because it's very messy otherwise to set a 'preference' Andrew, the block is written to assume there is some kind of method to determine 'who' is arriving at the page and interacting contextually with the block.In your use case, how would Rock know what to display to someone that it doesn't know who is? Something to consider: if someone clicks on an unsubscribe/preferences link that was sent to them via email (from Rock), it will tokenize their link, and Rock would&nbsp;then know that it's them (showing the appropriate choices).<a href="https://www.rockrms.com/Rock/BookContent/8/116#settingsubscriptionpreferences" target="_blank">https://www.rockrms.com/Rock/BookContent/8/116#settingsubscriptionpreferences</a>One option would be secure (require login) a special version of the Communications Preferences the page. If you also integrate Social login options (FB, Twitter, Google), you would at worst create some duplicates your team needs to clean upIf you outline your use case some more, you may get some more ideas and insight to accomplish the same goal using a combination of tools&nbsp;available in Rock

<p>TL;DR The block assumes the person is logged in because it's very messy otherwise to set a 'preference'</p><p><br></p><p>Andrew, the block is written to assume there is some kind of method to determine 'who' is arriving at the page and interacting contextually with the block.</p><p>In your use case, how would Rock know what to display to someone that it doesn't know who is?<br></p><p>Something to consider: if someone clicks on an unsubscribe/preferences link that was sent to them via email (from Rock), it will tokenize their link, and Rock <i>would</i>&nbsp;then know that it's them (showing the appropriate choices).</p><p><a href="https://www.rockrms.com/Rock/BookContent/8/116#settingsubscriptionpreferences" target="_blank">https://www.rockrms.com/Rock/BookContent/8/116#settingsubscriptionpreferences</a></p><p>One option would be secure (require login) a special version of the Communications Preferences the page. If you also integrate Social login options (FB, Twitter, Google), you would at worst create some duplicates your team needs to clean up</p><p>If you outline your use case some more, you may get some more ideas and insight to accomplish the same goal using a combination of tools&nbsp;available in Rock</p>

<p>TL;DR The block assumes the person is logged in because it's very messy otherwise to set a 'preference'</p><p><br></p><p>Andrew, the block is written to assume there is some kind of method to determine 'who' is arriving at the page and interacting contextually with the block.</p><p>In your use case, how would Rock know what to display to someone that it doesn't know who is?<br></p><p>Something to consider: if someone clicks on an unsubscribe/preferences link that was sent to them via email (from Rock), it will tokenize their link, and Rock <i>would</i>&nbsp;then know that it's them (showing the appropriate choices).</p><p><a href="https://www.rockrms.com/Rock/BookContent/8/116#settingsubscriptionpreferences" target="_blank">https://www.rockrms.com/Rock/BookContent/8/116#settingsubscriptionpreferences</a></p><p>One option would be secure (require login) a special version of the Communications Preferences the page. If you also integrate Social login options (FB, Twitter, Google), you would at worst create some duplicates your team needs to clean up</p><p>If you outline your use case some more, you may get some more ideas and insight to accomplish the same goal using a combination of tools&nbsp;available in Rock</p>

Save Cancel

Daniel Hazelbaker · Answer 2 · 2018-03-15T12:08-07:00

0

Daniel Hazelbaker replied 6 Years Ago

That block is designed to work with a signed in person so that it can save those subscription preferences. To use that particular block you would have to require them to login (or create a login) first. The problem with doing it without a login is you have a high chance of updating the _wrong_ person's preferences, and/or creating duplicate records each time somebody updates their preferences (which then wouldn't actually update their preferences since it's a new record).

Question

0

Subscribe Block

0

0