New: Enhance governance oversight with three big policy updates!

[Rachelgmoore]

Hello AppSheet Community,

I’m excited to share three big updates to policies in AppSheet:

1. Introducing the “Enforce always” policy stage, which allows a policy to be enforced the moment it is saved.
2. Policy compliance preview is now available when creating or editing any policy. This tool lets policy authors see how existing apps in a policy’s scope might be impacted before that policy is saved.
3. Updated default stages for most policy templates. We think “Enforce always” puts even more governance control in the hands of policy-creators, so we’ve made this the template default moving forward.

These features are rolling out now and are available to all users who can edit policies. Check them out in your account, or read on for more information.

Why use Enforce always?

In the world of AppSheet governance, policy “stages” specify when AppSheet’s policy engine should check if any non-compliant conditions or behavior exist – and if found, act against it. 

For example, if a policy’s “stage” is set to “on deploy,” any non-compliant behavior (e.g. actions that are not allowed per the policy’s condition against its specific component) detected when the app is deployed will be flagged. If the policy’s severity is set to “warn,” the app creator deploying the app will see a warning indicating their app is out of compliance but still be allowed to deploy. If the policy is set to “error,” the app creator will be unable to deploy their app. 

Sounds good - as long as all intended apps reach the “stage” checkpoint. 

But, if an app doesn't reach the “on deploy” checkpoint, the policy will not be enforced until it does. If an app remains in prototype state or the policy was created after the app was deployed, this means that it could possibly exist – and function – in a non-compliant state for an indefinite amount of time.

The new “Enforce always” policy stage launching now was designed to address exactly the case described above.  Setting a policy’s stage to “Enforce always” means that any app - regardless of its component, condition, severity, or otherwise - will come under control of this policy as soon as it is saved, allowing policy-setters maximum confidence in the governance boundaries of their AppSheet systems. 

Why use policy compliance preview?

Policies are powerful: Depending on its configuration, creators or users who attempt a noncompliant action can be totally stopped in their tracks. While preventing unwanted actions is often the reason organizations implement them in the first place, there may be some apps that are unintentionally or unknowingly out of compliance with a new policy. And, on the flipside, editing or creating a new policy may introduce checks that block the legitimate use of important applications. 

In either case, before now there was little policy creators could do to check whether a policy update would work as intended. The only way to determine if a policy would impact the right set of components, conditions, targets, and stage impacting the right apps in the right way was to test it live 🫣

Testing potentially breaking changes live, against production applications, isn’t ideal. It’s actually made even more risky by the addition of the Enforce always policy stage, which makes it relatively simple to deactivate a wide swath of apps as soon as a new error-severity policy is saved. That’s why we’ve coupled the release of Enforce always with the new policy compliance preview: 

Now, when configuring a policy, you can review policy compliance to confirm the results are as expected for each version (latest and stable) of your app. 

The policy compliance preview will show all apps this policy would impact – and whether they’re currently in or out of compliance with the proposed policy’s rules. Compliant apps will keep running, with no changes to their current functionality. If a policy is saved, apps listed in the Non-compliant section will see their behavior impacted depending on the proposed policy’s severity and stage. 

From this list, the policy-setting user can edit (or ask the creator to edit) non-compliant apps – or, if the policy itself is incorrect, update it accordingly. The compliance check will re-run in real time, so you can see the impact of changes as you make them.  

Updated policy templates

Before today, most predefined policy templates used “on app edit” as their default stage. Now, the majority of the predefined policy templates have been updated to use “Enforce always” as their default stage. We think the enforce now stage makes your AppSheet environment more secure than ever, but remember you can always edit the templated policy to suit your particular organization’s needs.

As of now, all predefined policy templates EXCEPT "Apps must have documentation,”  "Restrict who can deploy apps,” and “block external apps” now use “enforce always” as their default stage.

Bringing it all together

Together, Enforce always and the policy compliance preview make it easier than ever for admins to ensure their data is tightly controlled – while the apps connected to it remain working exactly as intended.

Please share your feedback in the thread below this message!

[Alexveo314]

Hi,

Great newes! enforce always is really nice, it will help us handle the backlog of all "pre-policies apps"

[Aurelien]

Hi @Rachelgmoore 

Thank you for this update.

I've been in touch with support over policy that is supposed to be evaluated regarding the user email, such as the template "restrict data source attachable to apps".

From my test, it does not work at the moment.

However, I would bring a suggestion: it may be interesting to have the possibility to run the policy evaluation regarding one's user account or email.

Thanks for consideration, and thank you for the great work achieved so far!

[WillVerkaik]

I believe https://www.googlecloudcommunity.com/gc/AppSheet-Q-A/Appsheet-URL-has-version-identifier-that-genera...   will have to be acknowledge and repaired, before this policy feature can be valid to use.  The current bypass issue takes any developer out of compliance validation as a result.