Job Owner Changes in Asset Bundle
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-14-2025 01:21 PM
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-15-2025 06:38 AM
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.
Data Engineer | Machine Learning Engineer
LinkedIn: linkedin.com/in/wiliamrosa
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-15-2025 05:50 AM
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]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-18-2025 02:46 PM - edited 09-18-2025 02:51 PM
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-000000000000The documentation below also includes some YAML examples:
https://learn.microsoft.com/en-us/azure/databricks/dev-tools/bundles/permissions
Data Engineer | Machine Learning Engineer
LinkedIn: linkedin.com/in/wiliamrosa