Managing Profiles Centrally

Define IT-managed add-in profiles in JSON and deliver them to clients with the ManagedProfilesPath policy

Managed profiles let IT publish a standard set of add-in configurations that appear in every user's Deck as read-only profiles. Users switch between them; they cannot alter them.

How it works

You author a JSON file describing one or more profiles.
You place the file where clients can read it - a UNC share or a local path pushed to devices.
You set the ManagedProfilesPath policy to that path. See Policy Reference.
On startup, Deck loads the file and shows the profiles as managed (read-only). Users select one to activate it.

Managed profiles are resolved against the add-ins actually discovered on each machine at activation time. They are not copied into the local database, so editing the JSON and refreshing policy updates every client.

To prevent users from creating their own profiles alongside the managed ones, combine this with ProfileManagementMode = AdminOnly.

File schema

{
  "profiles": [
    {
      "name": "Trading Day",
      "description": "Full market-data stack for the morning session",
      "mode": "allow",
      "addins": [
        "Bloomberg.Ribbon",
        "Refinitiv.Eikon.AddIn"
      ]
    },
    {
      "name": "Locked Down",
      "description": "Everything off except compliance tooling",
      "mode": "deny",
      "addins": [
        "Compliance.Archiver"
      ]
    }
  ]
}

Field	Type	Required	Meaning
`profiles`	array	yes	The list of managed profiles.
`name`	string	yes	Display name shown in Deck.
`description`	string	no	Subtitle shown under the name.
`mode`	`"allow"` \| `"deny"`	yes	How `addins` is interpreted (below).
`addins`	string array	yes	Add-in ProgIDs the mode applies to.

allow vs. deny

The mode determines how the addins list maps onto the machine's discovered add-ins:

allow - only the listed add-ins are enabled; every other add-in is disabled. Use this to define a minimal, known-good set.
deny - all discovered add-ins are enabled except the listed ones. Use this to block a few problem add-ins while leaving everything else on.

Because resolution happens per machine, an allow profile that lists an add-in a given machine doesn't have simply enables nothing for that entry - there is no error.

Finding an add-in's ProgID

The addins array uses the add-in's ProgID, which is the subkey name under the Office Addins registry key. Two easy ways to get it:

In Deck, open the Add-ins page and click an add-in; its detail view shows the ProgID and registry path.
In regedit, browse to HKCU\Software\Microsoft\Office\16.0\<app>\Addins\ (or the HKLM equivalent) - each subkey name is a ProgID, for example Bloomberg.Ribbon.

Use the exact subkey name, including capitalization.

Delivering the file

UNC share (typical): put the file on a read-only share, e.g. \\fileserver\deck$\profiles.json, grant the target users/computers read access, and set ManagedProfilesPath to that UNC path. Clients need network access to the share at Deck startup.
Local path: if you already sync a file to devices (Intune, ConfigMgr, a logon script), point ManagedProfilesPath at the local copy, e.g. C:\ProgramData\Vediram\Deck\profiles.json.

Set the policy at machine scope for device-wide profiles, or user scope to vary profiles by user. Remember machine scope wins if both are set.

Updating profiles

Edit the JSON in place. Clients pick up changes the next time the Core daemon starts (or after gpupdate + a Deck restart if you also changed the policy path). Because nothing is cached in the client database, there is no stale copy to clear.

Validation and troubleshooting

The file must be valid JSON and reachable at the configured path. Parse errors and unreachable paths are recorded in core.log.
If managed profiles don't appear, verify the policy value landed and the path resolves from the client - see Managed profiles not loading.

Policy Reference Managing Excel XLL Extensions