topic Re: Job Owner Changes in Asset Bundle in Data Engineering

Job Owner Changes in Asset Bundle

nickscip — Thu, 14 Aug 2025 20:21:36 GMT

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?

Re: Job Owner Changes in Asset Bundle

WiliamRosa — Fri, 15 Aug 2025 13:38:11 GMT

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.

Re: Job Owner Changes in Asset Bundle

T0M — Mon, 15 Sep 2025 12:50:53 GMT

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]

Re: Job Owner Changes in Asset Bundle

WiliamRosa — Thu, 18 Sep 2025 21:51:36 GMT

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