You can create policies to control the behavior of almost every aspect of the creation, management, and distribution of AppSheet apps.
When defining an app policy, you have two options:
- Use a predefined policy template. See Add a predefined policy .
- Write your own custom policy from scratch. See Add a custom policy .
Using a predefined template can help you to get a configured policy running quickly. You can also use a template as a starting point for writing your own customized version of a policy.
To write your own, more complex policies, you may want to create your own custom policy from scratch.
App policy templates
Template name
Description
Acceptable image resolution
Requires that images captured in apps meet a minimum specified resolution. See also Control image size .
Apps must have documentation
Requires that apps include documentation before they can be deployed. See App documentation on the About page.
- App creators are restricted from including AppSheet database tables in their apps
- End users are restricted from using apps that are built with AppSheet databases
Prevents app creators from setting up API-based integration with external cloud services that send data to an app.
Enabling this policy disables use of the AppSheet API. See Prevent app creators from enabling the API .
Prevents app creators from building an automation using Google Forms.
Prevents app creators from creating an app using Google Forms or adding a table using a form from Google Forms.
Prevents app creators from using webhooks in their apps. See Prevent app creators from using webhooks .
Enable offline use
Enforce FedRAMP compliance
Must sync-on-start
Requires that apps refresh their data each time they start. See Sync on start .
Only users from specific domain
Only allows users from specific domains to access apps.
Note: When configuring this policy template, you’ll need to replace ourdomain.com
and subdomain.ourdomain.com
with the specific domains to allow.
Prevent row delete
Prevents apps from deleting rows of data in their connected data sources by ensuring the Deletes option is always unchecked in table settings. See Control add, update, and delete operations .
Requires that access is only granted to users explicitly shared to an app in the sharing dialog . Only individual users users added directly to an app can access it, ensuring that sign-in is required and all access is explicitly managed through the sharing dialog. Restricts app access as follows:
- Require user sign-in
- Prevent all signed-in users from accessing the app (disable Allow all signed-in users )
- Disable Require domain authentication
Require sign-in
Restricts public access to apps by requiring users to sign in (authenticate) to access an app .
The Require sign-in policy applies to the app itself and doesn't necessarily restrict automation events that are triggered by changes made to external sources (e.g., automations triggered by submissions to a Google Form by external users).
App creators can configure their apps in ways that prevent AppSheet from identifying who is triggering the automation event. It is always the app creator's responsibility to ensure that external sources comply with their organizational rules and policies as well as AppSheet terms of service.
Restricts app sharing as follows:
- Prevents the sharing of apps with an entire domain using the Share dialog
- Limits the number of users that the app can be shared with using the Share dialog (defaults to 5, but can be customized)
See also: Share: The Essentials
The Restrict app sharing policy applies to the app itself and doesn't necessarily restrict automation events that are triggered by changes made to external sources (e.g., automations triggered by submissions to a Google Form by external users).
App creators can configure their apps in ways that prevent AppSheet from identifying who is triggering the automation event. It is always the app creator's responsibility to ensure that external sources comply with their organizational rules and policies as well as AppSheet terms of service.
Restricts user sign-in to one authentication provider. Google is the default.
To specify the authentication provider, use one of the following strings:
-
apple -
box -
dropbox -
google -
microsoft -
salesforce -
smartsheet
Restrict data sources
Restricts app access to specific data sources by data source name.
Restricts app sharing to only emails or domains internal to the domain belonging to the app owner's organization. For an AppSheet organization , this includes all secondary domains managed by the parent Google Workspace account, if applicable.
Prevents app creators from using external data sources and authentication domains in an app.
For Workspace users: Only Workspace authentication and data sources are allowed.
For non-Workspace users: The app editors are only allowed to attach the data sources to an app or integrate with the auth domains with the apps that are the same as the app owner's email domain.
See also:
Restricts AppSheet database sharing to only emails or domains internal to the domain belonging to the app owner's organization. For an AppSheet organization , this includes all secondary domains managed by the parent Google Workspace account, if applicable.
See also Restrict external database sharing .
Restrict providers attachable to apps
Restricts app access to specific data source types .
To specify data source types, use one or more of the following strings:
-
airtable -
apigee_api -
apple -
aws_cognito_domain - big_query
-
box -
data_studio( Looker Studio ) -
database(all cloud and on-premises databases) -
dropbox -
dynamodb -
google -
google_calendar -
google_tables(see also Disable AppSheet databases ) -
integration_connector -
mariadb -
microsoft -
mysql -
odata -
okta_domain -
openid_connect -
oracle -
postgres -
redshift -
salesforce -
sqlserver - sketch (to create an view apps using Spec )
-
smartsheet
Blocks users from accessing apps created externally to your organization.
For Workspace users with an AppSheet organization: Your "organization" is defined as all verified domains associated with your Workspace account. If an app is created in the same Workspace organization or verified domain, it is considered to be internal and will not be blocked.
For non-Workspace users or Workspace customers without an AppSheet organization: If an app is created in the app owner's email domain, it is considered to be internal and will not be blocked.
Restrict who can deploy apps
Restricts app deployment to specific app creators.
LIST(11111, 11122)
function in the policy condition expression. To determine the ID of an app creator, go to your team members page
and view the ID adjacent to the email address for each app creator on your team.Run as app creator
Ensures all apps run using the app creator’s identity to access connected data sources by ensuring that the access mode is set to "as app creator". See Access mode: as app creator or app user .
