Security

Overview

Security settings in the App Studio define the defaults for who can access, and edit both the App and its records. Proper configuration ensures that the right users and teams can collaborate effectively while maintaining appropriate data controls.

App Security is typically configured as the second-to-last step before publishing an app to Workspace. It includes settings for:

• App Visibility – Who can see the app in the Workspace Launchpad. (Viewing in Child Context is governed by the Integration set in the Parent App along with any indirect Navigation).

• Record Access – Who can view or modify records created within the app.

• Edit Permissions – Who can see the App in App Studio to edit the App structure.

Note: Changes to app security take effect in the next published version. If a Record was created prior to the released version then it will maintain the access that was already in place before the App was Published.

• Use Case: Configuring Security for a Decisions App

• App Visibility

• Default Records Access Rights

  • 'For All Teams'

  • Access Right Priority

• App Edit Access Rights

Use Case: Configuring Security for a Decisions App

To give context we will look at building a Decisions App available to multiple business units. You want to ensure:

• The app is visible to the following teams: Directors, Operations, Technical, and Sales.

• Records created within the app are:

  • Fully editable to the Directors team

  • Read-only for Operations, Technical, and Sales teams

  • App Builders have access to edit the App in App Studio
  • We also have an external contractor who can add his own decisions but not see others

This ensures that decisions are made by leadership, while other teams can stay informed without modifying the data.

App Visibility

App Visibility can be restricted to specific teams and or users and gives users visibility of the App in the Launchpad. To select multiple Teams and Users utilise the drop-down lists.

Is Hidden decides if to show the application in workspace to anyone, this overrides what teams and users have been set.

Note: If an Application is not hidden and no teams or users have been selected for App Visibility then the Application will be visible to all users.

1. Navigate to the Security section of your app.
2. Ensure the Is Hidden toggle is off so that the app is visible.
3. Under App Visibility, select the appropriate teams and users.
4. Click Save and publish to take effect.

For our Decisions App we need to give accessibility to the Directors, Operations, Technical Sales and our External Contractor. So we make sure the 'Is Hidden?' flag is not set and then add in our teams and the specific user into the Visible by Team and Visible by User.

Default Records Access Rights

By default, when a new record is created in an App it will only be visible to the user that created it via an Owner Access Right. Every Record has an Owner who will always have Full access to the Record. This is to stop records from being created or updated without security. Otherwise if a record has no security no one will be able to see it or recover it but it will still be in the app.

In this section, you can add teams that will additionally have access to newly created records. Read-Only and Full Access can be set for teams in the relevant list.

Note: In the case of a Child and Parent Record creation, when a Record in a Child App is created it inherits the access from the Parent and not the access set up in the Child app itself. It will still set the Owner of the Record as the one who created it.

1. Scroll to the Default Records Access Rights section.
2. If All Teams should have either Read Only or Full access then set the appropriate toggle.
3. Under Full Access, select the teams that need to be able to edit all created Records.
4. Under Read Only Access, select the teams that only need to view the Records created in the App and not edit them.
5. Click Save and publish to take effect.

'For All Teams'

There is the option to give a ReadOnly for All Teams or Full for All Teams access right. This does not apply an access right per team, rather it adds an 'All' Access Right which means the ReadOnly/Full Access is applicable to all Users via one access right. It means if new Teams are added or old Teams are removed from the site then this does not impact the purpose that All Users have access under this right.

If an All access right is added then it will not additionally allow individual team selection. The All Access right must also be either ReadOnly OR Full.

Looking at this in context of our Decisions App, the benefit of selecting ReadOnly would be that should we have an additional Team added such as 'HR', then we do not need to retrospectively add this access right on all existing Records. The flip side of this is that should our new HR team not be supposed to have access then the 'All' access right would need removing and individual team access added to all existing Records. Forethought here for the most likely scenario is key to reducing manual security management as your userbase grows.

Access Right Priority

Access Right priority is as follows:

• Firstly: User Access Right --> Team Access Right --> All Access Right
• Then: Full Access --> Read Only Access

Note: 'For All Teams' should be used with caution As sites grow Apps may need to be restricted to particular teams. It is better to set Teams so security is maintained as your portal scales without the need to

Setting the Record Access for our App we need to make sure that the External Contractor only has Full Access to his own Decisions. Then that the Directors have Full Editable Access to all Records created and that these are only Read Only to the Operations, Technical and Sales teams.

In the screenshot above we can see this achieved by setting Full for Directors and Read Only for all other Teams who need it.

As our contractor is not in one of these teams he will only see his own Records. If he needed Read Only or Full access to the other Decisions then we would need to add him to either an existing Team or create a new one for Contractors.

App Edit Access Rights

This section is part of the overall App Governance process in the business. Note that it is important that whenever changes are made to any application that the App Executive sponsor or ‘owner’ and core users are informed so an internal process should be established.

Initially, App Edit Access Rights will be set to the User that created the Application. Only that user will have visibility of the App in the App Studio Launch Pad. Additional Users and Teams can be given Access to Edit the App.

If no users or teams are selected then the App will be open and any user with App Studio Access will have access to edit the App. 

1. Scroll to the App Edit Access Rights section.
2. Under Editable By Team, select the teams that need to be able to edit the App configuration.
3. Under Editable By User, select the users that need to be able to edit all created Records.
4. Click Save and publish to take effect.

In the Decisions App we have set that members of the App Builders team can see the App in App Studio and make edits. We have also set it up so that our contractor can make App Edits as well as for the purpose of our use case we will assume his role covers Technical Process Improvements.

Note: App Studio Permission will also need to be set for each User in their Profile in order to first access App Studio.