So, I have an app that I have been working on in my personal tenant for a music cruise we are going on in a few months. I posted screen captures in a Facebook group for people going on the cruise. There was interest from several people in using the app. Have any of you published an app for something similar where you may not know how many users will use it, or when? In looking at the PA licensing Microsoft is doing away with the Per-App Plan and going to a model where if someone uses it, then you get charged through Azure billing (Pay As You Go - or PAYG). The App is mainly going to be used during the one-week period of the cruise. Would it be better to remove the sharing of the app with the users, remove the connection between the app and Azure billing, or both? I don't want to be picking up the tab for 10$ per person per month in between. How would you go about billing the users to reimburse the cost of the Azure billing? I have attached some screen captures here in case anyone is interested.

🤔 Entities, forms, views, relationships, roles, and permissions >> "My current project is a Model-Driven App (CRM) with Business Central integration. My role focuses on implementing entities, forms, views, relationships, roles, and permissions. However, I feel that I don’t yet have a complete overview of how the whole system works. I can connect small pieces, but I don’t fully see the big picture." --- #️⃣ The Mental Model: A Database with a Living Face The most important thing to understand about Model-Driven Apps (MDAs) is that they are not built like traditional applications. Most software is built code-first — a developer writes logic, and the UI is crafted around that logic. MDAs flip this: they are data-model first. Everything you see on screen — forms, views, dashboards — is generated automatically from the underlying data structure you define. This is why they're called "model-driven." Think of it this way: you define the shape of your data, and the app emerges from that shape. #️⃣ The Four Layers (and How They Stack) It helps to think of the whole system as four distinct layers sitting on top of each other. 1️⃣ Layer 1 — The Data Layer (Dataverse) At the very bottom is Microsoft Dataverse, which is essentially a cloud-hosted relational database with superpowers. Every "entity" you create (like Account, Contact, Opportunity, or a custom one) is really just a table in Dataverse. The columns (fields) you add to that entity are the columns of that table. The relationships you define between entities are foreign keys — Dataverse just makes them feel more semantic (one-to-many, many-to-many, etc.). This layer is the source of truth. Everything else in the app is a view into or interface over this layer. 2️⃣ Layer 2 — The Metadata Layer (the "Model") On top of the raw data sits metadata — the definitions of how data relates, behaves, and validates. This includes your relationships (which entities are connected and how), field types and validation rules, and crucially, Business Rules (declarative logic you define without code, like "if Status = Closed, make Revenue required"). The metadata layer is what makes this a model-driven app — the model is this rich description of your data and its rules.