The best way to think of an application is a deployment of your interface. An application is the wrapper around an interface that brings it to life.
An application has the following properties
Primary Domain Name
The primary domain of which this application is accessed. Example: myapp.com or website.com
Secondary (Redirect) domains
Additional domain names that redirect to this application. Example: www.myapp.com or www.website.org
User Interface
The layout and interface that will be rendered when a user opens this application.
Interface Version
Configuration specifying which version of the interface should be rendered. For example, Consider this typical scenario:
You may have an interface you are working on, and 2 applications a staging application and a production application.
The staging application might be set to show the current working draft of your interface whilst you're working on it, and the production application set to only show a published milestone.
Other scenarios might include using the same interface but with different configuration for different departments of your organisation.
Application Permissions
Configure roles and scopes for the application, that are attributed to the application's static access token. so that it can load and render content from the database.
User Permissions
Configure additional roles and scopes attributed to users that authenticate into this application.
As you may store many different types of content in your database, when building applications it's important to specify what content the application can load and render on screen. You don't want to give your public website access to all your customer's personal information, but you likely want it to be able to display your logo. Luckily with the fine grained permissions provided in the platform you can secure your content, right down to the field level.
When creating a public website, there are a few things you want to keep in mind.
SEO
You want your website to be indexed by major search engines and rank as highly as it can, you also want people to be able to search for the content in your site. For this reason it is important that your application token is static, so that when content is indexed the search engine can always find it at the same place at a later time
Unauthenticated website visitors
Unless you are hardcoding all of the content on your website, you likely will need to load some data from your database, including images, logos, articles etc. So the typical setup is to create a Public Website Visitor user role that grant's basic 'view' access to images, videos and other content and add that into the Application Permissions with an appropriate realm. We recommend only granting permissions to the specific fields that it requires so that 1. It keeps your sensitive data secure, and 2. The website will load less data and use less bandwidth loading fields that it doesn't actually need.
When creating a secure intranet, we would assume that all users must be logged in to access content. Because of this we can disregards SEO concerns, leave the Application Permissions empty, and rely on granting specific users access passes and roles. This way no data can be loaded until a user signs in, and then only the data that user has been granted permissions to view will be able to be loaded into the application.
This would be a hybrid, where you may have a website that the general public can view forum posts and comments, but must sign in to be able to post comments, in addition you may want to promote individual users to a 'Moderator' role so that they can 'edit' and 'delete' content. For this scenario a setup might look like this
Application Permissions
Public Forum User Role
granting permissions to view forum posts
User Permissions
Authenticated Forum User Role
granting permissions to create forum posts, and create comments
Specific Individual Users
Grant the Forum Moderator access pass, that gives extra permissions.
As the permissions are additive, if an unauthenticated user visits the forum application, they will be able to do all of the actions granted from the 'Public Forum User Role', Then if they log in or sign up to the application they will be granted all of the permissions from the `Public Forum User Role` AND the `Authenticated Forum User Role. If they log in as a user that has been granted additional permissions they would have total combined permissions of all 3 roles.