Job Owner Changes in Asset Bundle

[nickscip]

When I deploy a fresh job, I'm set as owner, which makes sense because I'm creating it.
Then at some point, the owner switches to a service principal. This is strange. I believe it happens when a scheduled job triggers.

Can job owners change?

[WiliamRosa]

If you see the job owner changing after an Asset Bundle deploy, it’s because ownership defaults to the principal that performs the deployment (the PAT/SPN used by the CLI). To keep ownership stable, deploy with a dedicated service principal and set it explicitly in the bundle: add a permissions block on the job giving that SPN (or a group) the role IS_OWNER, and use run_as so the job executes under the same identity. Avoid ad-hoc edits in the UI—saving changes there will flip ownership to the editor. In short: pin owner via permissions.IS_OWNER, run the job via run_as, and perform all deployments with the same SPN to prevent owner drift.

[T0M]

Could you please add an example of this for me, please? 😅

```yml
targets:
  prod:
    mode: production
    permissions:
      - service_principal_name: asdf1234
        level: IS_OWNER
```

Error: invalid permission level: IS_OWNER, allowed values: [CAN_MANAGE, CAN_VIEW, CAN_RUN]

[WiliamRosa]

Hi @T0M, how are you doing?

You’re right about the statuses at the level above the job; however, my reference to IS_OWNER comes from the job-level statuses, as shown below:

IS_OWNER exists and is valid for resource-level permissions (e.g., inside resources.jobs.<id>.permissions). The docs list the allowed levels per resource type and, for Jobs, they include IS_OWNER.

At the bundle top-level permissions block (either the root permissions or targets.<env>.permissions), the only allowed values are CAN_VIEW, CAN_MANAGE, and CAN_RUN — it does not accept IS_OWNER

Example:

bundle:
  name: my-bundle

resources:
  jobs:
    my-job:
      name: My Job
      permissions:
        - service_principal_name: 00000000-0000-0000-0000-000000000000
          level: IS_OWNER            # allowed on the Job resource

targets:
  prod:
    permissions:
      - group_name: data-engineering
        level: CAN_VIEW              #top/targets only accept VIEW/MANAGE/RUN
    run_as:
      service_principal_name: 00000000-0000-0000-0000-000000000000

The documentation below also includes some YAML examples:
https://learn.microsoft.com/en-us/azure/databricks/dev-tools/bundles/permissions