Anonymous User in Mendix from a Hotel Manager’s Perspective

Did you know that Europe has 219,000 hotels in which 426 million nights were booked in 2022 alone? All these guests needed to register themselves before gaining access to their rooms. In order to register, they are, of course, allowed to enter the hotel anonymously and identify themselves at the reception to gain access to the hotel’s private facilities, like the rooms, pool, spa, etc.

Many hotels offer quite some facilities that unregistered (anonymous) hotel visitors can use — services like the lobby, restaurant, toilet, terrace, the bar, and perhaps a souvenir shop. These are accessible to anonymous hotel guests, and the hotel does not need to know who those anonymous users are. It’s for use without registration.

Now, when you register at the hotel to get to your room, you feel safe since all the people you see in the ‘protected’ part of the hotel are registered guests. Only registered guests are allowed to take the elevator and go to the level of their rooms. When you booked, you paid for the room and not for the elevator and the corridor, which might suggest you don’t need to register just to use them. Yet, the hotel does not allow anonymous guests to use the elevators and walk on the levels of the rooms — even if they do not use a room. They just have no business there. To get to the rooms, or the levels where those rooms are, you need to be registered (or identify yourself), or you are not going to get there. The hotel wants to provide a safe environment and avoid unforeseen, unwanted situations.

Now, let’s take this concept to your Mendix application. Your application might have some features, functionalities, or pages an anonymous user can use. But don’t let anonymous users access modules that are also used by registered users. Simply put, they don’t belong in the area where only registered users have access. Instead, gather all the pages, microflows, and entities together in one module, and grant anonymous users access to that one module. Don’t let anonymous users take the elevator to your domain model with persistent data. Give them their own non-persistent entities, and process only the essential input from anonymous users into the database.

In short, welcome your anonymous users with great hospitality and support them in any way so they will register or identify themselves in order to use the protected facilities of your application.