How can we handle non-users or minor-users that are neither anonymous nor real users?

0
This is a very common situation I see we having to deal in almost any application I can think of. I want to know how can we handle Mendix billing for certain types of “minor-users” non-anonymous people , that are not actual paying application subscribers. Examples: - A dental office management app has doctors, nurses, and admins as paying users, but also must accept input from dental office clients (minor-users) to schedule appointments, ask questions, view billing, etc. -A Service Desk app has admins, technical support, managers, as paying subscribers, but also has people that request services and need to be informed of service status, be able to pay for the service, get service updates, etc.       
asked
1 answers
0

Hi Andre, that's a great question. Thanks for posting it on our ISV Space!

 

First of all, I would like to invite anyone else reading this question to feel free to reply, as there are multiple ways to achieving this. It would be great to hear other's opinions on this.

 

I think the answer to your question completely depends on your business requirements, and therefore there is not possible for us to answer it 100% fittingly. However, below more information on how to decide what approach would be best. Let's stick to your term of ‘minor-users’, to prevent confusion. Just a few initial questions that come to mind are:

  • What do you expect these minor-users to be able to do, specifically, in your solution and how do they interact with your solution?
  • How will you provide/constrain access to the information you want them to be able to read/write?
  • Do minor-users need to be able to, after having input information, come back at a later stage and make changes to what they input earlier?
  • Are you using a third-party IdP?

All of these questions/business requirements (and more!) combined will result in a fitting technical approach, perhaps multiple. Mendix allows for either anonymous or named users, so you should first decide which of these fits best. Seeing as the ISV license allows for unlimited named users, you are not limited by this in how you want to solve this. It is up to you to decide how you want to approach this, technically.

 

You could opt to create an account for these minor-users, which would give your minor-users login credentials. This makes it easy to constrain the data they're allowed to see. Once they are finished with their input, a case is completed or an appointment is finished, you could delete the account again – or not. This could also be managed via your own IdP. The fact that they are not paying subscribers could/should be distinguished by them having a different user role than your other users.

 

If you don't want to create an account for them, they would need to be able to visit your solution as an anonymous user. Security then becomes something to carefully design. Not that the option with named users means security is less important, but with anonymous users you need to think of ways to constrain the data in anther way. It is definitely not advised to simply say an anonymous user has access to all appointments, etc. 

 

When it comes to constraining data and security, here are some links to potentially relevant information:

I hope this helps! Let us know what approach you chose and what you've learned from it, so others in our community can also learn.

answered