When talking to partners, we’ve come to understand that our existing process for on boarding a smaller set of users involves too many steps. We’re working on an optimized flow for an in app way to add up to 5 users at a time and we wanted to share it to gather feedback!
The current, multi-step process involves first create creating a contact, and then creating a place for that contact for each new CHW. You then create a user, choosing the place and contact you just created:
We believe this process will greatly improve the user management experience for administrators, but would love to hear any thoughts or concerns from the community!
This is definitely an easier way compared to the current approach. Have you also thought about uploading more than 5 users at a time? Perhaps maybe have an option where a user can upload an excel with the same tabular format specified in your screenshot.
It’s also really great to hear that you think a more bulk interface, powered by CSV/Excel upload, would be helpful! Indeed, we actually started with a more feature rich option where the CHT admin would first download an empty CSV template with the correct column headers. They would then populate this and upload it back to the CHT.
In the end, error handling, development time and what would be most impactful based on partner interviews became concerns. To be able to deliver a feature sooner, MVP (Minimum Viable Product) style, we decided to start with a simpler feature, as shown above, and then iterate from there.
Hi @ojwangantony, @andrineM and @Lavatsaleo,
We would be happy to hear from you on any improvements we can make on this feature to help improve the current flow of the user creation process for AfyaSTAT users.
The proposed feature is very exciting. Our biggest challenge on user creation where searching of a place name returns so much data, including names of patients. I think we need filters on the contact type so that users are shielded from so much data that they don’t need at the time
searching of a place name returns so much data, including names of patients. I think we need filters on the contact type so that users are shielded from so much data that they don’t need at the time
The searching you’re referring is on this “Place” field when creating/editing a user, correct?
And can you give me some more specifics about your deployment please? Mainly how many levels in your hierarchy are there and about how many places and CHWs do have you created?
Great - thanks again for the details. So I appreciate how hard it is to find a user in the “Place” field, how many users do you have total in your CHT instance? I’m wondering what a worst case is for trying to find a user with the “Place” field where too many results are returned.
We don’t have a central deployment for CHT as other implementations and the number of CHT users vary from one facility to another. I had given an average of 15 users per facility in my previous response.
I think it would be nice if the search feature in CHT can be made configurable. The current behavior should be the default but should be overridden if an implementer decides to narrow down the search to just particular variables within the contact registration forms. I know this will likely introduce problems with indexes but again it’s something that should be considered in a future release.
Helping with bulk user creation is an amazing effort. I’m afraid that in my experience, most of our projects are managing many users. I’m afraid adding 5 users might not be “enough bulk” - our user creation activities typically come by the hundreds.
Instead of the proposed interface limited to 5 users, I’d personally love to see some sort of web spreadsheet for editing and adding users. Give us something we can copy/paste into from excel or Google Docs and that will work to create 100s of users. Our teams often manage users in spreadsheets already and this would be very convenient for us
What would the data look like in the contact docs that are created? For projects with contacts that have required attributes, this might cause data integrity issues. Can we add required attributes somehow?
If not, will we be able to turn this feature off?
Instead of the proposed interface limited to 5 users, I’d personally love to see some sort of web spreadsheet for editing and adding users.
Yes - this was actually Allies team first idea after talking with your App Services team at Medic. The ability to have App Services, a technical partner or capacity built admin be able to add >100 of users via a CSV would be achieved by first downloading a template from the CHT which would include all the relevant columns. The admin would then fill it out offline and then upload it to the CHT, thus bulk creating >100 users at a time.
However, after further interviewing existing CHT admins, the bulk add idea featured in this forum post was the one that was found to be the most impactful. A tough choice, for sure!
What would the data look like in the contact docs that are created? For projects with contacts that have required attributes, this might cause data integrity issues. Can we add required attributes somehow? If not, will we be able to turn this feature off?
Great points! Indeed, the approach in this post is simplistic. It does not account for contact forms that have been extended to have required attributes outside of the 5 shown columns. This feature internally will use the new /api/v1/usersAPI endpoint which actually has a small set of required fields. The net result would be users created with this feature may have data integrity issues.
We wanted to validate our assumption of this being impactful by making a Feature Release that partners could test. If not, and being able to turn it off and not having every possible field were blockers, then the Feature Release would either be improved to add features or not be iterated on further and deemed a failure.
