Private Apps may specify ACL entries that relate to certain Users Teams. These follow specific resolution rules:

Direct team members and Admins (at any point in the tree) will always have access to an app owned by that Team.
User ACLs take precedence over Team ACLs.
Deny ACLs take precedence over Allow ACLs of the same type.
An Allow ACL will evaluate all members at or above (and optionally below) a certain Team in the hierarchy.
- This means, by default, direct and inherited members of a Team will gain access to that Private App.
  - Disabling the team’s inheritance flag will, therefore, also not allow permissions to propagate.
- ACLs can specify to include descendants, meaning any child (or grandchild, etc.) team will also get access to that Private App. Note that this bypasses the Team inheritance flag - that is, even if users don’t flow down, this App’s grant still will.
A Deny ACL will evaluate all members directly assigned to (or optionally below) a Team.
- This means, by default, a Deny rule will block access to only that team’s members.
- If the “include descendants” flag is set, the Deny ACL will include all members of all child teams, again bypassing the Team inheritance flag.
  - It is very unlikely that “Deny without inheritance” will be used in practice, but the option is there.

Example

While this privilege model is complex, it can generally be simplified to “privilege flows downward, access flows upward.” Users at the top of a team hierarchy are generally granted the broadest scopes, while users at the bottom are generally the most restricted. Consequently, apps at the bottom of a team hierarchy are generally accessible to the most members, while apps at the top of the hierarchy are generally the most restrictive.

Consider the following (intentionally very convoluted) example:

[TEAM] Free Company
 ├── [USER] Alice (admin)
 ├── [USER] Bob   (developer)
 ├── [APP] FC Portal
 ├── [TEAM] Static Members (inheritance: true)
 │    ├── [USER] Diana (admin)
 │    ├── [USER] Eve   (developer)
 │    ├── [APP] Gear Request
 │    └── [TEAM] Trial Players (inheritance: false)
 │         └── [USER] Faythe (member)
 └── [TEAM] Artisans (inheritance: false)
      ├── [USER] Grace (member)
      ├── [APP] Material Tracker
      ├── [APP] Sales Reports
      ├── [TEAM] Crafters  (inheritance: true)
		  │    └── [USER] Heidi (member)
      ├── [TEAM] Gatherers (inheritance: true)
      │    └── [USER] Ivan (member)
      └── [TEAM] Marketboard Masters (inheritance: true)
           └── [USER] Judy (member)

App: Attendance Tracker (owned by Diana)
	ACL: Allow Static Members, do NOT include descendants
	
App: Performance Notes (owned by Diana)
  ACL: Allow Trial Players, do NOT include descendants

App: Gear Request (owned by Static Members)
	ACL: Allow Artisans, include descendants
	ACL: Deny Gatherers, include descendants
	ACL: Allow Ivan
	ACL: Deny Eve
	
App: Material Tracker (owned by Artisans)
	ACL: Allow Artisans, include descendants
	
App: Sales Reports (owned by Artisans)
	No ACLs configured.
	
App: FC Portal (owned by Free Company)
	ACL: Allow Free Company, include descendants
	
App: Potion Seller (owned by Ivan)
	ACL: Allow Free Company, include descendants
	ACL: Deny Artisans, do NOT include descendants

The following table shows who can access which application.

	Alice	Bob	Diana	Eve	Faythe	Grace	Heidi	Ivan	Judy
Attendance Tracker	Yes	Yes	Manage	Yes	No	No	No	No	No
Gear Request	Manage	Manage	Manage	Manage	No	Yes	Yes	Yes	Yes
Performance Notes	Yes	No	Manage	No	Yes	No	No	No	No
Material Tracker	Manage	No	No	No	No	Yes	Yes	Yes	Yes
Sales Reports	Manage	No	No	No	No	Yes	No	No	No
FC Portal	Manage	Manage	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Potion Seller	Yes	Yes	Yes	Yes	Yes	No	Yes	Manage	Yes

Example

Privilege Breakdown: Attendance Tracker

Privilege Breakdown: Gear Request

Privilege Breakdown: Performance Notes

Privilege Breakdown: Material Tracker

Privilege Breakdown: Sales Reports

Privilege Breakdown: FC Portal

Privilege Breakdown: Potion Seller