Creates a new profile or updates an existing one. Profiles can contain multiple content items (apps, files, commands, settings) and support versioning, batch rollout configuration, device targeting conditions, and execution scheduling.

Creating a profile that installs an app (the app was previously saved with the Files APIs and you have its repositoryFileMetaDataID):

{
  "name": "Install Sales App",
  "desc": "Installs the sales APK",
  "typeOfAllowMultiProfile": false,
  "profileCondition": { "profileConditionItems": [] },
  "profileExecution": { "when": "WHEN_IMMEDIATE" },
  "profileSubItems": [
    {
      "id": "665f1c2ab77e4a3d9c0e8b12",
      "type": "packages",
      "persistent": true,
      "stopAfterExecution": false,
      "repoItem": {
        "@class": "com.viso.entities.AppRepoItem",
        "repositoryItemId": "665f1c2ab77e4a3d9c0e8b12",
        "repositoryItemName": "Sales App",
        "repositoryFileMetaData": { "repositoryFileMetaDataID": "665f1c2ab77e4a3d9c0e8b12" }
      }
    }
  ]
}

All three IDs are the app's repositoryFileMetaDataID returned by savefiledata; only the ID is needed - the server resolves the full app details from the repository. Always include profileCondition (at least with an empty profileConditionItems list) - devices skip a profile that has no condition object.

Which profile a device runs (important when more than one profile is attached to a device's groups):

• Profiles with typeOfAllowMultiProfile: false (the default) are priority profiles: on each device only ONE of them runs - the one with the lowest orderIndex whose profileCondition is met. Other priority profiles attached to that device's groups are delivered but not applied.
• Profiles with typeOfAllowMultiProfile: true ('Run with other templates') run on every matching device in addition to the active priority profile.
• A new profile is appended at the lowest priority (highest orderIndex). Reorder with POST /rest/manager/profiles/updateprofilespriorities.
• Nothing enforces this at attach time - attaching a second priority profile to a group succeeds, and the device simply keeps running the higher-priority one. If the app must be installed regardless of other profiles, set typeOfAllowMultiProfile: true.

Rolling out a new version of the app (the same flow the management console uses):

1. Upload the new APK (getpresignurl -> PUT -> getpresignfinal) and save it as a new repository item with savefiledata (no repositoryFileMetaDataID), same packageName, strictly higher versionCode. Note the new ID.
2. Read the current profile with GET /rest/manager/profiles/getprofilebyid?profileID=<id> and replace the three IDs of the packages sub-item with the new item's ID.
3. Save it as a draft: POST createorupdate with draftVersion: true, linkedProfileId: <id> and no top-level id. Optionally review with GET /rest/manager/profiles/getprofiledraftversion?profileID=<id>.
4. Publish: GET /rest/manager/profiles/activateremoteprofileversion?currentProfileID=<id>&draftProfileID=<draft id>&isViewProfile=false. The profile version increments and devices upgrade the app in place (Android upgrade - app data is kept; devices already on that version report no change).
   Updating the existing repository item in place (savefiledata with its repositoryFileMetaDataID) also bumps every profile that contains it, but it is a full replace of the item, sends no push, and the console blocks it for items linked to a profile - prefer the flow above.

Detaching or deleting a profile does not uninstall its apps or revert its settings on devices; it only stops the profile from being applied and enforced.

Create vs. update vs. draft:

• Create: omit id. The new profile is saved as version 0 and becomes active immediately; attach it to device groups with attachprofiletogroups to start distribution.
• Draft update (recommended): send the modified profile with draftVersion: true and linkedProfileId set to the active profile's id, and omit the top-level id (leaving id in while draftVersion is true overwrites the active profile instead of creating a draft). The response returns the draft's profileID. The draft does not reach devices until you call activateremoteprofileversion.
• Direct update: send the profile with its existing id (no draft fields). The version increments immediately, but no push is sent - devices pick the change up on their next sync. Prefer the draft flow.

Response example:

{ "result": "SUCCESS", "data": { "profileID": "665f2a91c33e5b4ea1d7f003", "profileVersion": 0 } }