[James Noronha]

Hi MaryAnn,

Thanks for chatting about this last week, it definitely helped clarify both what you were seeing vs. expected behaviour. Before responding we did bring it up with SOC and hit on both what we should see and what we can do which is inline with what we were talking about. I hope this clarifies things a bit:

The issue arises from a combination of security / user permissions at both the club/data admin level and specifically if a head coach / team manager or someone with permissions for a club attempts to add someone who has never been part of their club before. When adding someone who has not been part of a club previously (i.e. someone who is either currently active or is expired and previously active in a club) the club level administrator (head coach / team manager) does not have permissions on that record, as such they cannot approve the enrollment and it has to be kicked up a level to a Community Level Data Administrator / Community Coordinator / Registrar for approval.

I’ve checked with Farkhanda and this should only happen if someone other than the member themselves (either the athlete / family member on behalf of athlete) enrolls the person. The reason for this behaviour is one of security: If a head coach / community coordinator can add anyone across the province and approve that addition then they would effectively be able to get access to any member record anywhere and all of their personal information regardless of where that member was located (which is untenable from a privacy perspective, the operating principal of the system is that an administrator should only have access to the records that they need to see and that there are some level of checks to ensure that they can’t see the records they shouldn’t). Community Level Data Administrators have a higher level of permission to be able to see everyone in their community and already have access to those records and can thus make that determination.

Now (and this part is important). That behaviour will not happen if someone enrolls themselves in the program. In a situation where an athlete, volunteer or family member on behalf of same registers the volunteer then the coach of the program will be able to approve the registration.

The trick as noted by MaryAnn is that it isn’t readily available on the screen that the Data Admin sees as to which ones require your approval (which should only be the ones that the coaches add directly who are new to their club) vs. which ones can be approved by the coaches (the majority, including already existing members and people who enrolled themselves or family members).

Here’s the good news. In bringing this up with Special Olympics Canada last week, they have the option in the portal connector to be able to add a column that would flag those records (and that we should be able to filter that list on) so that we’ll be able to easily see which ones you need to approve and which ones you don’t. We don’t want to remove your ability to see whose pending in the queue but that should address the major concern. I don’t have timing for the next rollout but it will be prioritized on that list.

The expected behaviour will thus be this (and this is, to be clear the behaviour right now, minus the ability to filter your approvals list for only the ones that require your approval).

1. A member enrolls themselves in a program that they have either been in before (but are expired) or are currently in (re-enrollment) –> Head Coach / Team Manager can approve at Club level.
2. A member enrolls themselves (or a family member) in a program that they have never been in before (new to the program) –> Head Coach / Team Manager can approve at Club level.
3. A Head Coach / Team Manager enrolls an athlete (not part of their family) who is already a member of their program (active) or has been a member of their program previously (expired / inactive) –> Head Coach / Team Manager can approve at Club Level
4. A Head Coach / Team Manager enrolls an athlete (not part of their family) who is NOT already a member of their program or has never been part of the program before (new enrollment)  –> Community Level Approval Required (Data Admin, Community Coordinator, Registrar)

We would expect that the club level administrators would be able to see the people that require their approval, and that the community level administrators would be able to see everyone (both club level and community level approvals required). The additional feature which would clarify things would be that the community level user would be able to filter their view (and would have an additional column to highlight) those that require their action so they don’t have to spend time figuring that out. That last bit has been added to our workplan.

Hope that provides some clarification on what should happen, and what needs to be updated. Thanks for taking the time to run through it with me, the talk we had definitely helped in how we explained what was needed to improve that part of the system.

James

[James Noronha]

The end user should be able to update their media release (we’re looking into this on another question at the moment as well).

There was some discussion with legal about allowing admin users to change that media release status and it was recommended that only the member be permitted to do so, which is why its restricted from an administration level.

 

[James Noronha]

Hi Lynda,

I’m pretty sure that when someone completes a new enrollment, it will allow you to confirm that information (and they’ll be able to change that status). They should be able to make that change. We’ll look into why its greyed out. If you could email Farkhanda with an example of someone who can’t we’ll see if we can trace that issue.

J

[James Noronha]

Will look into that one! It’s a good suggestion.

[James Noronha]

Hi MaryAnn,

That’s definitely a good suggestion to administrative users when you’re evaluating if two individuals are in fact the same person.

We do consider Nickname when we are looking at duplicate records, but it is not included in the automated function because nickname isn’t consistently used and has a higher amount of variability.

[James Noronha]

Has been added to the list of suggested modifications for Report 54

[James Noronha]

With apologies for the delay. Its a great suggestion and in chatting with SOC on a number of things last week, the utility of such a report across all chapters was very well received. Thanks so much for providing details on needed fields that simplifies things significantly for the developers.

To be clear to all reading this thread, this report would address the distinction between reporting on New Enrollments to programs vs. New Members Registering in a community (i.e. creating their account and going through the process for the first time). It would greatly help with processing of new members at the community level.

Its been added to the list of reports in development. We’re waiting to hear what the timeline is for the rollout of the next set of updates.

[James Noronha]

Great suggestion. We’ve started compiling a list and we’ll make sure that’s part of the FAQ for easy referral. If anyone has any suggestions for glossary items that we may want to make sure we include or that are confusing to them, please don’t hesitate to add them to this thread and we’ll be sure to update that list!

[James Noronha]

Hi MaryAnn,

Thanks for the suggestion. There are actually a couple of potential ways to do this, but all of them require us to make sure that our sessions and clubs are setup consistently the first time and that the data is valid, which is partially the reason that we can’t implement this straight away. Once we have the first set of sessions and registrations under our belt and can perform a proper validation of the new sessional data for this year, we will be examining a couple of potential ways to implement this for the coming year.

It’s definitely been heard and its on our list!

James

[James Noronha]

Good point! Will do!

Also DA = Data Admin!

 

[James Noronha]

Thanks for the flag, I think this one may have already been addressed in the update, but we’ll run a test next week and if it hasn’t we’ll move to address that.

James

[James Noronha]

Thanks MaryAnn, the notifications for the forum should be fixed now, we were able to trace the problem with the information you provided.

Yup we’ve noticed that with respect to the email labels as well. Its on our list of clarifications and should clean things up a bit. I suspect it might be included in the update coming soon.

[James Noronha]

Hi Lynda,

This question is actually related to another on the new Report 13.

Originally we had provided instructions that gave you email address 1, 2 and 3 respectively and allowed you to use those as you may. However as it turns out that was a bit erroneous on our part.

The Membership system is closely linked to the Donations Management System (as they are all contact management systems). However Ontario is only using the Membership system at the moment.

What we hadn’t properly realized was that Email 1 – is the Portal Address, Email 2 is the Donor Profile Address and Email 3 is the alternate address (if a user had one).

When Membership Report 13 was updated that became apparent because with all the other updates, there was a clarification on the fields (that was requested by all the chapters using the donation system) which caused some confusion on our end.

We are in the process of correcting that in bulk for everyone to avoid the confusion. Therefore if Data Admin (quite rightly and through no fault on your end) used Email 2 as an alternate address, we’ll be bulk moving those addresses to the Alternate Address field. If both the Email 2 and Email 3 field are in use we’ll be flagging those records and will get back to you to figure out how to reconcile that situation. We’ve put in a request to make sure that Report 58 and Report 13 match up accordingly, which should help there too. Apologies for the confusion.

James

[James Noronha]

Hi there Lynda,

Thanks for the feedback. We’ll make a note of this, all good points. I know they are balancing a fine line between things used all the time and things referenced, but good suggestions. We’ll add it to the list.

[James Noronha]

Hi there Peggy,

There’s a list of reports on the development pathway and I believe that this is one of them. We don’t expect that communities would have to develop that report on their own but we will be including some training during the webinars on existing reports for coaches and teams, and we are making notes of reports that would be beneficial. This one is definitely on that list.

James