Hi Karthik,

Welcome to OutSystems and this community! I'll try to answer your questions:

1. On a technical level, Server Actions can always be called. If you need some kind of Role-based restriction, you'll need to create that yourself. Note that on a typical consumer app on mobile there are no Roles, as the user is only in control of their own data. If it's a business app, you'll probably have roles, and you need to make sure programmatically that a user can't access information not meant for them.
2. "All Exceptions" is just that, a catch-all of all Exceptions. It's not an exception type that gets thrown, just like "Database Exception" is probably a catch-all of all database exceptions. What these categories are for, if that if you add an Exception Handler to an Action or Screen Flow, you can pick what that handler will handle: All Exceptions, only Database Exceptions, only Security Exceptions, etc. Typically you'll only handle "All Exeptions" in an Action, but handle Security Exceptions differently on a Screen Flow to redirect to a login page, for example. Note that exceptions are caught in order of specificness. So if you define a handler for a Database Exception and one for All Exceptions, a Database Exception will be caught only by the Database Exception handler, and all other exceptions will be caught by the All Exceptions handler.
3. The Mobile Button Group widget had its Variable on the Group level, you can't specify a Variable per button, only the value. From this follows that all Values of the Buttons should have the same type, that of the Variable of their Group.
4. Aggregate Functions in an Aggregate (Group, Count, Sum, Min, Max) are always applied to a single Attribute (the OutSystems name for a column). If you Sum() an Attribute, only that Attribute will be in the output. If you need the sum per, say, category, you need to Group on the category Attrribute. Since Entity Ids are unique (if they are the primary key, that is), you can never meaningfully group on them. What you display based on the Aggregate output is of course your choice.
5. There are only two system roles, and those are "Anonymous" and "Registered". Every user that is not logged in has "Anonymous" as their only Role, any user that's logged in has a Role of "Registered". Those two roles will always show up on the Logic tab, "Roles" folder. If you add custom Roles, and you assign a user to one or more Roles via a GrantXxxRole() or via the Users eSpace, after that user logs in they possess all of the Roles that are assigned to them, including the "Registered" role. Roles are independent of each other, and do not "overrule" each other, so even a logged-in user has the "Anonymous" role.
6. This is indeed the case. If a Cordova plugin is added, or you want to use a new version of a plugin already included, this means changes to the actual code of the native app that's generated, and you'll need to install it on the device. Changes to Screens and logic do not need a new app installation, as they are pushed automatically (and the user will see the blue "your app has been updated" notification on top of the screen).

EDIT: Checked on Anonymous role, and changed description accordingly.

Thanks Kilian for the detailed response. Appreciated!

Just a few iterations to my query to be precise after noting your response.

1. Mobile Application involves a combination of client action & server action and in cases, data actions, if needed. My query is - What's the mandatory time when the Mobile Application while operating looks for or checks for Server based response/validation. Is it at the time of Login, during rendering, when navigating from one screen to another or say, while clicking a Save button? Or is their no such mandate a Mobile application will require Server interaction and can act stand-alone (Its presumed - the logic and the local database are so defined to handle).

2. So when no specific exception handler is defined, can i presume - system will transfer the flow to "All Exceptions" when an exception arises (or) System understands the exception is due to an database issue and is smart enough to transfer the flow to "Database Exception" Handler.

3. Clear and Understood.

4. Clear and Understood.

5. In a business App, can i presume - we need to define the clear roles for every user created and a user can't be left without a role assigned and Outsystems will throw error if published without assigning?

6. Clear and Understood.

Thanks Once again!

Hi Karthik,

1. Server Actions are implemented as REST calls. They will fail if you are not online. If you want to design an app that can work offline, then you need to check yourself whether it's online before each call to (a set of) Server Actions. In general, you should limit calling Server Actions as much as you can - even when online, it takes much more time than a local action.
2. A specific Exception will be handled by a specific Exception Handler. If no such handler is found, it looks for a handler one step up in the Exception hierarchy:

So if an "Invalid Login" exception occurs, the system will look for a handler of "Invalid Login". If it can't find one, it will look for a handler of "Security Exception", and if it can't find that one, it will look for a handler of "All Exceptions". So typically you will have at least an All Exceptions handler, and other handlers if you need them.

5. You create Roles based on your functional requirements. You can create an actual role in the sense of "Manager" or "Data Entry Employee", or you can create more task-based roles like "CanEditCustomerData", "CanViewPatientStatus" or whatever makes sense for you. Using the Users eSpace, you either assign roles directly to a user ("John Smith is Manager" or "John Smith gets CanEditCustomerData and CanViewCustomerPurchase roles"), or you can assign Roles to a Group, and put Users in the Group (which will then inherit those Roles).

Note that Roles only come into play when the application has been started, and/or when the user has logged in. At publish time, Roles only exist on code-level, and whether or not there are users assigned to roles is completely out of scope (and should be - who has what roles should not be left to the developer!). The Platform will only throw an "error" (an exception in the sense we've been discussing above) when the user wants to access a Screen they don't have access to.

Thanks Kilian & the detailed responses are clear enough. Good day!

You're welcome! Happy coding :)