---
title: "Working with Scheduler Jobs"
slug: "scheduler-1"
updated: 2025-09-16T13:43:34Z
published: 2025-09-16T13:43:34Z
canonical: "documentation.encodify.com/scheduler-1"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://documentation.encodify.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Working with Scheduler Jobs

## Overview

---

The **Scheduler** in Encodify allows you to run background tasks automatically at defined intervals. Typical examples include synchronizing file systems, importing data, or triggering scheduled workflows. Once configured and started, jobs will run periodically based on their defined intervals until stopped.

The Scheduler functionality in Encodify allows you to:

- Configure scheduler jobs
- Start and stop scheduler jobs
- Monitor scheduler tasks

## Accessing Scheduler Properties

---

> [!WARNING]
> **Note:** Only Encodify administrators should modify `System.properties`, as incorrect settings may affect critical system functionality.

Access to **Scheduler Properties** is controlled via the `schedulerPropertiesEditors` parameter in the `System.properties` file.

- Specify a **comma-separated list of User IDs** allowed to edit Scheduler properties.
- Use `*` to grant access to all users.
- Users not listed will **not see the Scheduler Properties button**.

## How to enable Scheduler Jobs

---

### Configuring Scheduler Jobs

Scheduler jobs must be configured before they can be run. Each job can have one or more tasks with specific parameters.

Steps to configure jobs include:

1. Navigate to **System Configuration → Sites → System Status → Scheduler**.
2. Click **Scheduler Properties** to view or edit jobs.
3. Add a job definition in free text format.
4. Click **Save Changes** to apply your changes.

### Key parameters

A typical scheduler job configuration includes:

| Parameter | Description |
| --- | --- |
| `joblist={Job_Name}` | Defines the job or a comma-separated list of jobs to run. Uncomment to activate. |
| `#joblist={Job_Name}` | Comment out to deactivate a job. |
| `job.{Job_Name}.param.UserID=` | User ID under which the job runs (recommended to use a dedicated administrator account). |
| `job.{Job_Name}.type=` | Specifies the job class (e.g., `dk.encode.ebms.scheduler.FieldImportJob`). |
| `job.{Job_Name}.interval=` | Interval in seconds at which the job will re-run. |
| `job.{Job_Name}.startimes=` | Optional comma-separated list of start times. |
| `job.{Job_Name}.SiteID=` | Site ID the job applies to (some jobs may ignore this). |

> [!WARNING]
> **Note:**Only one `joblist` parameter can be defined in the properties file, but it can include multiple jobs as a comma-separated list. All other joblists must be commented out.

### Example Job

Example of the job configuration. This configuration runs the `fieldImport` job every 10 seconds using the specified user.

```plaintext
joblist=fieldImport
job.fieldImport.param.UserID=11536
job.fieldImport.type=dk.encode.ebms.scheduler.FieldImportJob
job.fieldImport.interval=10
```

## Starting and Stopping the Scheduler

---

To start and stop the scheduler, follow the steps below:

1. Go to **System Configuration → Sites → System Status → Scheduler**.
2. If no jobs are running, the status will show **Currently stopped**.
3. Click **Start Scheduler** to begin execution.
  - Status will update to **Currently running**.
  - The **Running Scheduler Jobs** section lists active tasks with their current status (*Running* or *Stopped*).
4. To stop execution, click **Stop Scheduler**.
  - The Scheduler will finish all active tasks before shutting down.

## Monitor Scheduler Jobs

---

Active scheduler jobs can be monitored via the **Running Scheduler Jobs** section in the UI. Each job displays its current status: **Running** indicates the job is actively executing, while **Stopped** means the job has completed. Use the **Refresh** button to update job statuses while the Scheduler is running.

## Notes and Best Practice

---

- Always **test new job configurations** in a controlled environment before production.
- Use a **dedicated service account** with administrator rights to avoid permission issues.
- Only **one joblist can be active** at a time; all others must remain inactive.
- Changes to `System.properties` should only be performed by an administrator.