Interface CreateJobRequest

List of permissions to set on the job.

The id of the user specified budget policy to use for this job. If not specified, a default budget policy may be applied when creating or modifying the job. See effective_budget_policy_id for the budget policy used by this workload.

An optional continuous property for this job. The continuous property will ensure that there is always one run executing. Only one of schedule and continuous can be used.

Deployment information for jobs managed by external sources.

An optional description for the job. The maximum length is 27700 characters in UTF-8 encoding.

An option to disable auto optimization in serverless

Edit mode of the job.

• UI_LOCKED: The job is in a locked UI state and cannot be modified.
• EDITABLE: The job is in an editable state and can be modified.

An optional set of email addresses that is notified when runs of this job begin or complete as well as when this job is deleted.

A list of task execution environment specifications that can be referenced by serverless tasks of this job. For serverless notebook tasks, if the environment_key is not specified, the notebook environment will be used if present. If a jobs environment is specified, it will override the notebook environment. For other serverless tasks, the task environment is required to be specified using environment_key in the task settings.

Used to tell what is the format of the job. This field is ignored in Create/Update/Reset calls. When using the Jobs API 2.1 this value is always set to "MULTI_TASK".

An optional specification for a remote Git repository containing the source code used by tasks. Version-controlled source code is supported by notebook, dbt, Python script, and SQL File tasks.

If git_source is set, these tasks retrieve the file from the remote repository by default. However, this behavior can be overridden by setting source to WORKSPACE on the task.

Note: dbt and SQL File tasks support only version-controlled sources. If dbt or SQL File tasks are used, git_source must be defined on the job.

A list of job cluster specifications that can be shared and reused by tasks of this job. Libraries cannot be declared in a shared job cluster. You must declare dependent libraries in task settings.

An optional maximum allowed number of concurrent runs of the job. Set this value if you want to be able to execute multiple runs of the same job concurrently. This is useful for example if you trigger your job on a frequent schedule and want to allow consecutive runs to overlap with each other, or if you want to trigger multiple runs which differ by their input parameters. This setting affects only new runs. For example, suppose the job’s concurrency is 4 and there are 4 concurrent active runs. Then setting the concurrency to 3 won’t kill any of the active runs. However, from then on, new runs are skipped unless there are fewer than 3 active runs. This value cannot exceed 1000. Setting this value to 0 causes all new runs to be skipped.

An optional maximum number of times to retry an unsuccessful run. A run is considered to be unsuccessful if it completes with the FAILED result_state or INTERNAL_ERROR life_cycle_state. The value -1 means to retry indefinitely and the value 0 means to never retry.

An optional minimal interval in milliseconds between the start of the failed run and the subsequent retry run. The default behavior is that unsuccessful runs are immediately retried.

An optional name for the job. The maximum length is 4096 bytes in UTF-8 encoding.

Optional notification settings that are used when sending notifications to each of the email_notifications and webhook_notifications for this job.

Job-level parameter definitions

The performance mode on a serverless job. This field determines the level of compute performance or cost-efficiency for the run. The performance target does not apply to tasks that run on Serverless GPU compute.

• STANDARD: Enables cost-efficient execution of serverless workloads.
• PERFORMANCE_OPTIMIZED: Prioritizes fast startup and execution times through rapid scaling and optimized cluster performance.

The queue settings of the job.

An optional policy to specify whether to retry a job when it times out. The default behavior is to not retry on timeout.

The user or service principal that the job runs as, if specified in the request. This field indicates the explicit configuration of run_as for the job. To find the value in all cases, explicit or implicit, use run_as_user_name.

An optional periodic schedule for this job. The default behavior is that the job only runs when triggered by clicking “Run Now” in the Jobs UI or sending an API request to runNow.

A map of tags associated with the job. These are forwarded to the cluster as cluster tags for jobs clusters, and are subject to the same limitations as cluster tags. A maximum of 25 tags can be added to the job.

A list of task specifications to be executed by this job. It supports up to 1000 elements in write endpoints (:method:jobs/create, :method:jobs/reset, :method:jobs/update, :method:jobs/submit). Read endpoints return only 100 tasks. If more than 100 tasks are available, you can paginate through them using :method:jobs/get. Use the next_page_token field at the object root to determine if more results are available.

An optional timeout applied to each run of this job. A value of 0 means no timeout.

A configuration to trigger a run when certain conditions are met. The default behavior is that the job runs only when triggered by clicking “Run Now” in the Jobs UI or sending an API request to runNow.

The id of the user specified usage policy to use for this job. If not specified, a default usage policy may be applied when creating or modifying the job. See effective_usage_policy_id for the usage policy used by this workload.

A collection of system notification IDs to notify when runs of this job begin or complete.