Prebuilt Apps Policy Inheritance

Prebuilt Apps settings inherit through your policy hierarchy, but they don't simply flow straight down. Two distinct rules govern what a device ends up with:

1. Inheritance with override — how a setting passes from a parent policy to its children, and how a child can break from the parent.

2. Most restrictive wins — how Addigy resolves a conflict when a device ends up subject to more than one value at once.

This article covers both, then walks through how they apply to the Menu Bar and to update frequency.

Inheritance with override

Prebuilt Apps settings can be found in Policy > Software > Settings. By default these settings are inherited down to child policies. Prebuilt Apps allows admins to change the default inheritance behavior in Addigy with inheritance override: a child policy can be configured with a different value than its parent.

• Application configurations: a child policy can set a different app configuration than its parent. 

• Deployment schedules: a child policy can set a different schedule than its parent. That overridden schedule then becomes the parent schedule for its own children.

Conflicting Settings

Inheritance/override decides what flows down a single chain. Separately, when a device belongs to more than one policy with conflicting settings - which can happen with Flex Policies, Addigy applies the most restrictive value. This keeps device behavior predictable instead of random when policies overlap. What "most restrictive" means depends on the setting:

Menu Bar inheritance

The Menu Bar is an opt-in feature — off by default. You choose where to turn it on across your policy hierarchy. It has three possible values:

The examples below use this hierarchy:

• Parent (top-level policy)

  • Child

    • Grandchild

      • Great-grandchild

When you turn the Menu Bar On or Off, Addigy shows a confirmation message telling you which policies the change will inherit down to before it is applied.

Scenario 1 — Turning it On at the top

Set the Parent to On. The setting inherits all the way down, and every device in the hierarchy receives the Menu Bar.

Scenario 2 — Overriding to Off partway down

Parent is On, but you override the Grandchild to Off. The Grandchild's Off becomes the new parent for everything below it. Devices in the Parent and Child still receive the Menu Bar; devices in the Grandchild and Great-grandchild do not.

Scenario 3 — You can't override an Off back to On from below

Continuing from Scenario 2, the Grandchild is Off. If you try to turn the Great-grandchild back On, you can't — the option is greyed out, because a higher policy has explicitly set Off and Off is the most restrictive value.

Scenario 4 — Order of operations (an Off above unsets an On below)

Suppose you first set the Grandchild to On, then later set the Parent to Off. Setting the Parent to Off shows a warning that it will unset the On you previously made in the Grandchild. Behind the scenes, the Grandchild's On is unset, and it displays the greyed-out, inherited Off state.

Scenario 5 — Default in the chain

The Parent is left at Default (unset). You set the Child to On. The Child and everything below it receive the Menu Bar, even though the Parent is unset. Devices that are only in the Parent do not receive it.

If you then change the Parent from Default to an explicit Off, you'll get a warning that it will unset the On in the Child. After that, nothing below receives the Menu Bar — an explicit Off cannot be overridden from below.

What happens when you move a policy

When you move a policy, its Menu Bar behavior depends on the new parent:

• Moving under a parent set to Off: if the moved policy was On, its On is unset and it inherits the Off. Devices in the moved policy will not receive the Menu Bar.

• Moving under a parent that is Default/unset: if the moved policy is On, it keeps On, and that On inherits down to its own children.

Flex Policies and Self Service Configurations

The greyed-out indicators and automatic unsetting described above work within a policy hierarchy. They do not yet surface conflicts in these cases:

• Flex and location policies: if a device belongs to multiple flex/location policies with conflicting settings, the most restrictive value still wins — but you may need to check those policies manually to find where it is coming from. There is no combined view of this at this time.

• Self Service configuration: a Self Service configuration with the Menu Bar turned off acts as an Off and will prevent the Menu Bar from deploying. To learn more about Self Service please see this article: https://support.addigy.com/hc/en-us/articles/4403549553171-Creating-a-Self-Service-Configuration

  • If the Self Service configuration has the Menu Bar turned on, but the policy does not have the menu bar configured- the Menu Bar on the device will only show Self Service items, and not Prebuilt Apps Updates.

Update frequency inheritance

Update frequency controls how often the update notification prompts the user — for example, every 4 hours or every 8 hours. Like other PBA settings, it inherits down and can be overridden by a child policy. When a device ends up subject to conflicting frequencies, the most restrictive (shortest) interval wins: 4 hours takes precedence over 8 hours, so the user is prompted on the more frequent schedule.