Question

Photo of Michael Manning

0

DOES ANYONE "REQUIRE" A LOGIN PRIOR TO USING CMS

5

The powers to be have made the decision to NOT require logins as it takes too long for people to do registrations, giving etc... especially when they forget their logins and passwords. Anyone have comments on this issue and maybe similar issues without requiring logins.

I am constantly merging accounts and now I'm seeing multiple scheduled transactions appearing on peoples giving... no login is required UNTIL someone decides they want to Manage the scheduled transactions... a little late at that point.

  • Photo of Jim Michael

    1

    Your experience is quite common. Organizations have to choose user convenience (and some pain for staff) vs. making them authenticate (some pain for them, but cleaner data) as you can't really have both.

    Here, we chose to require authentication for Events because it enables the ability to pick other people from your family and register them... something quite common here. Without that, they have to enter data for every registrant (often wrong, or using their own email/phone, which really trashes data). We already had a culture of people having logins from our prior ChMS so it wasn't a hard sell. OTHER orgs would never entertain that, though, and would ALWAYS want it to be the easiest, friction-less experience for the end user regardless of what that means for staff to clean up. We also do NOT require authentication for giving (except to see history, obviously) because our leaders felt that was too high a barrier.

    So pick your camp ;-)


  • Photo of Jeremy Hoff

    1

    What Jim said. :-)

    I'll add this: dupes happen. It's just reality.  Rock has several mechanisms that help prevent them, but users always find a way to get around them.

    I recommend having someone watch your "Data Quality" area as a key part of their job. Even better: a team.

    Consider setting up some charts/metrics so that there is a visual showing how many dupes / possible dupes / merge requests / bad names / dupe addresses / dupe phone numbers / dupe email addresses / etc.. I suggest adding a column on the "Possible Duplicates" page that indicates whether a record has giving attached - handle those merges FIRST (especially toward the end of the calendar year) before looking at the rest.

    Also consider using the "URLEncodedKey" option within your marketing. Consider the security implications, but it could help with dupes while at the same time making it easier for your congregation. In practice, it means that for last year's families you will send them a "Sign up for Camp Again" email with an embedded URLEncodedKey link that authenticates them.... 

    Hope that helps,

    • Eddie Holeman

      Eddie Holeman

      We do quite a bit of what Jeremy said about the URLEncodedKey. When we are reaching out to a group of people via email asking them to take action, we normally use a person token in the provided url. Helps get people to take the action. Otherwise, for event registrations we require login and we use the https://community.rockrms.com/recipes/180/prompt-for-login idea on our givenow page to encourage login, but not require it.

    • Photo of Michael Manning

      0

      Jim, is this an all or nothing situation or can we require a login account for giving purposes specifically? I know on our general giving page it doesn't require any account unless you pick the option to Manage your scheduled transactions. Could we require login account for all giving OR at least if they are wanting to create a scheduled giving? 

    • Photo of Jim Michael

      0

      It's not all or nothing... you can choose what parts of Rock you want authentication on, and not have it on others. To make giving be "behind" authentication, you just need to modify the (Give Now) page rights. 
      1. As Admin, to to the Giving | GIve Now page on your public site.

      2. In the Admin toolbar (hover at the bottom of the page to make toolbar appear), Click the lock symbol... you should see that "All Users" are inheriting View rights to this page.

      3. ADD two new rights to this page: All *Authenticated* users = Allow, and All *Users* = Deny

      4. Save, and now when you click Give Now from the menu you will be prompted to enter credentials to access that page. This works the same on any Rock page, and is the way you "make someone log in" to get to certain pages. If you only wanted CERTAIN people to access the page, you would put those people in a Security Role, then give the ROLE View rights, followed by All users deny.

      As for making it only prompt when creating a scheduled transaction... I don't think that's possible with the way the giving page is set up, because you CREATE a scheduled transaction ON the same page you give once... so that one page is either behind authentication, or it's not. You will also notice that the other "giving" pages like Manage Giving Profiles and Giving History already have these rights as I describe above.

    • Photo of Josiah Rocke

      0

      @jeremy - could you do a recipe on these suggestions?

      We are on the fence. Starting to require login on events - what is nice is that is handled PER REGISTRATION, so it's not a page setting. I've seen a recipe that pops up a box on pages where it is added that suggests the user log in for the best experience. We will probably take that tack.

      Now...how to get old people to stop typing in "Bob & Sue" in every blessed form with a first name field....

      • Jim Michael

        Jim Michael

        Ping @daveschuster in Rocket chat on the "&" problem. He has some JS we add to various pages with forms that prevents people from doing "Bob & Sue" or "Bob and Sue" and it pops up a box explaining that they should only enter one person in that field.