When you start creating multiple apps, either as an individual app creator or as a member of a team, there are typically constraints and guidelines that should be applied to every app created. App policies are the means by which to express these constraints and guidelines.
The typical reasons to set up app policies are:
- Design consistency
- Corporate compliance
What Are Policies?
Policies are rules that limit how AppSheet apps are created, managed, and distributed. In plain English, policies look like this:
- Every app must require users to sign in.
- Data cannot be deleted though an AppSheet app.
- Only certain people can mark apps as deployed.
- Apps can only be shared to a specific email domain.
- and so on.
Each policy has three important components:
- Condition: a constraint that is checked on each app.
- Severity: Error, warning, or info. This tells the platform how to handle the condition if not satisfied.
- Stage: When should the policy be checked? The most common choice is to choose the Deployment Check phase.
There are also some other options, including descriptive messages.
What Are the Requirements to Set Up Policies?
Any AppSheet account can set up policies for itself. Simply navigate to Account >> Policies and set up policies to remind yourself or enforce certain settings.
If you have an AppSheet business subscription with Team Governance, your account admin will designate one AppSheet account to be the ROOT. This account can set up policies that will be enforced in all dependent AppSheet accounts.
What Types of Policies Can be Created?
You can create policies on almost every aspect of the app creation, management, and distribution of AppSheet apps. There are a set of pre-defined templates you can use to get going quickly, or you can define more complex policies through custom policies.
To start creating policies, navigate to Account >> Policies >> Add Policy and select a template:
Each policy explained:
- Require sign-in: each app must require user sign-in.
- Only users from specific domain: users in the app allow-list must be from a specific domain.
- Run-as-app-creator: ensure that apps are not configured to run as the app user.
- Prevent row deletion: ensure that apps cannot delete data.
- Acceptable image resolution: require a minimum resolution for captured images.
- Must sync-on-start: require that apps refresh their data each time they start.
- Enable offline use: require that apps be configured to run offline.
- Restrict who can deploy apps: specify the emails of the app creators who are allowed to create deployable apps.
In each of these pre-defined policies, you can observe the condition definition. For example, the Require sign-in policy has the condition,
[AuthRequired] = true. Notice that the syntax for conditions is identical to the expression syntax used in the rest of AppSheet.
The Custom policy template lets you create a rule based on a specific component of the AppSheet service. To create a custom policy:
- Select a component from the list (see below).
- Define a condition. The properties vary by component.
- Select the severity for non-compliance.
- Select the stage at which it should be applied.
- Add description of the policy.
- Add success and failure messages .
Almost every aspect of the app definition can be governed by policies.
Corporate Team Governance
Customers in corporate and enterprise subscriptions have the ability to manage other AppSheet accounts under their team through an AppSheet ROOT admin account.
The ROOT admin can set policies that will apply to all accounts in their team.
- When you create a policy, start by defining a lower severity level (Warning or Info), so you don't immediately block users that may already be out of compliance. This is important if you want to preserve the availability of the apps they created.
- Experiment with the pre-defined policies. If you want to define a policy that is not pre-defined, try using the custom policies. We are happy to help.