Email → Submit a JAMS Job

When a matching email arrives, an email flow can submit a job in JAMS Scheduler, passing values from the email as the job's parameters. Nothing needs scripting on your side: the job already holds the work (PowerShell, a command, SQL, a file transfer, whatever its type is), and the email tells it what to work on.

Example: an alert email says Server: SQLPROD02. The flow submits \Ops\Disk\Cleanup with its ServerName parameter set to SQLPROD02.

First read Email: Taking Action Automatically. It explains the two modes (run automatically, or ask the person paged) and what happens when something goes wrong. This page covers the JAMS Scheduler side.

At a glance

In JAMS Scheduler, make sure the job exists and has a parameter for each value the email will supply.
On the email flow, pull those values out of the email (e.g. Server).
Tick Submit a JAMS job, type the job's path, and click Validate.
Give each parameter a value, e.g. {{Server}}.
Choose whether you want to hear when the job fails (on by default) or completes.
Test with a sample email, then save.

Before you start

You need:

The JAMS Scheduler integration set up, with a JAMS Incident Connector (Agent) paired on your JAMS server. If you already receive JAMS Scheduler alerts with Restart / Continue, you have this.
The job you want to run, already defined in JAMS Scheduler, with a parameter for each value the email will supply.
Permission for the Agent's JAMS user to submit that job. The Agent submits as the same JAMS user it already uses for remediation:
- JAMS 7.9.2 and later (New API): the user the API token belongs to.
- Legacy API: the user name and password entered in the Agent's setup.
That user needs Submit access to the job and to its folder.
Values to pass, set up in the flow under Pull values out of the email. See Email: Conditions & Values from the Email.

Set it up

Open the email flow (or create one in the flow builder) and set up its conditions and values.
Tick Submit a JAMS job when this email arrives.
Choose Submit automatically or Ask the person paged.
JAMS Agent: choose the Agent (JAMS Incident Connector) on the JAMS server where the job lives. If you only have one, it's chosen for you.
Job: type the job's full path, starting from the top folder, e.g. \Ops\Disk\Cleanup. Forward slashes work too.
Click Validate. The Agent asks JAMS Scheduler whether the job exists and what parameters it has. You'll see ✓ Found Cleanup · 3 parameters, and a row appears for each parameter.
Fill in each parameter's value (see below). An empty box says Not set, which means the job's own default is used. A parameter JAMS requires that has no default shows Required: not set in red, and the flow can't be saved until you give it a value.
Under When the job finishes, choose whether to alert the recipients if the job fails (on by default) and whether to tell them when it completes (off by default). See When the job finishes.
Use Test with a sample email (in the conditions section) to check your values pick up what you expect, then save.

Who can set this up: an admin of your account. The section appears once your account has the JAMS Scheduler integration and an Agent (JAMS Incident Connector) is connected.

Why you type the path: jobs are picked by path rather than from a browse list. Validate checks it straight away, so a typo shows up while you're editing, not when the email arrives.

Parameters

The parameters must already exist on the job

The email cannot create parameters or change the job. It only supplies values, for that one run. The job definition in JAMS Scheduler stays exactly as it is.

So the process is:

In JAMS, add the parameters the job needs (e.g. ServerName) and use them in the job as usual.
In the email flow, press Validate again. The new parameters appear, ready for a value.

If you type a parameter name the job doesn't have, it's refused. It's never quietly ignored or added, because then the job's real parameter would silently not get its value. Hidden parameters (the ones JAMS doesn't show when submitting by hand) aren't listed by Validate but can still be set by name. The form shows "JAMS didn't list this parameter" so you can double-check the spelling.

Reading the values in a PowerShell job

JAMS Scheduler passes a job's parameters to a PowerShell job by name, so the safest way to read them is a param() block at the top of the job's source:

param(
    [string]$ServerName,
    [string]$ApplicationName,
    [string]$AlertReference
)
Write-Output "Collecting diagnostics for $ApplicationName on $ServerName"

Values read this way are always treated as text. A value like x'; Remove-Item … can never run as code. Avoid pasting values into the script with <<ServerName>> inside quotes: a value containing a quote mark could break out of them. And never pass a value to Invoke-Expression.

What a value can be

Each value can be:

fixed text, e.g. 5 or nightly;
a value from the email, e.g. {{Server}};
a mix, e.g. Ticket {{Ticket}} from {{from}}.

These placeholders are available:

Placeholder	What it is
`{{YourValue}}`	Any value you defined under Pull values out of the email
`{{subject}}`, `{{from}}`, `{{to}}`, `{{date}}`	The email's subject, sender, recipients and date
`{{body}}`	The email's full text, with its line breaks, up to 32,000 characters. Your job can read it as a normal text parameter.
`{{alertId}}`	The ID of the alert, so the job can refer back to it

Data types

After Validate, each parameter shows its data type. The value from the email must make sense for it, or the job is not submitted (and people are paged, or told, with the reason):

JAMS type	The value must be…	Examples
Text	anything	`SQLPROD02`
Integer	a whole number	`5`
Float	a number	`2.5`
Boolean	true or false	`true`, `False`
Time	a time of day	`14:30:00`
Date / DateTime	a date JAMS understands	`2026-10-20`, `today`

Required parameters with no default must get a value. The flow won't save without one, and if the value from an email turns out empty, the job isn't submitted and people are told why.

Choosing the job from the email (advanced)

The job path can include a value too, e.g. \Ops\Restart-{{Service}}. When it does, you must also fill in Only inside with a folder (e.g. \Ops), and the job must be inside that folder. Otherwise anyone who can email the mailbox could choose which job runs. A path that would leave the folder, or contains .., is refused.

Validate can't check a path built from the email, because the job isn't known until the email arrives.

What "success" means

A submit is successful when JAMS Scheduler accepts the job and gives it an entry number. The entry number is recorded in the audit log and appears in the message people hear in Ask mode: "JAMS job Cleanup was submitted as entry 48213."

Success means the job was submitted. Whether it then completes is up to JAMS. See the next section for how you hear about that.

Each submit is noted in JAMS Scheduler as "Submitted by JAMS Incident Management for alert …", so operators can tell it apart from a manual one.

On the dashboard, the alert's Job column shows the job's name and its entry number.

When the job finishes

JAMS Incident Management follows the submitted job in JAMS Scheduler, through the same Agent, until it finishes. Under When the job finishes on the flow:

Setting	Default	What happens
Alert the recipients if it fails	On	If the job ends in Error or Fatal, the flow's recipients get a new alert: "JAMS job Capture Diagnostic Snapshot (entry 1020), submitted for "…", failed: …". A job that ends with a Warning is reported too.
Tell the recipients when it completes	Off	If the job succeeds, the recipients are told. Leave it off when you submit automatically, or people are paged for a job that worked.

Things to know:

Nothing to set up in JAMS Scheduler. You don't need a JAMS Notification Job for this.
No double alerts. If JAMS Scheduler already alerts JAMS Incident Management when this job fails (through a Notification Job), you get that alert, not a second one.
It follows a job for up to 24 hours. If the job still hasn't finished by then, you're told once, if fails is on, and it stops following the job.
Every outcome is in the audit log, even when no one is notified.
The notices go to the flow's recipients in the usual order, with an Acknowledge choice.

Viewing the job's log

An alert that submitted a job has View Log, on the dashboard and in the notification history. The log is read from JAMS Scheduler, through the Agent, each time you open it:

While the job is running, you see the log so far. Press Refresh for more.
After it finishes, you see the end of the log (the last 500 lines), which is where a failure shows.
The log is not stored by JAMS Incident Management. It is read when you look, and only then.

Following the job and viewing its log need the JAMS Incident Connector 0.9.15 or later, with JAMS Scheduler 7.9.2 or later and its New API. With JAMS Scheduler's older API, JAMS Incident Management can tell when a job finishes only while it is still in the JAMS Monitor, and View Log says the log is in JAMS Scheduler.

Troubleshooting

What you see	Why	What to do
The Submit a JAMS job section doesn't appear on the flow	You aren't an admin, your plan doesn't include the JAMS Scheduler integration, or no Agent (JAMS Incident Connector) is connected	Ask an admin, or connect an Agent from JAMS Scheduler.
Validate: There is no JAMS job at …	Typo in the path, or the Agent's JAMS user can't see the job	Copy the path from JAMS Scheduler (folder and job name). Check the user has access.
Validate: The Agent didn't answer in 30 seconds	The Agent service is stopped or the server is offline	Start the JAMS Incident Connector service on the JAMS server.
Validate: This server's Agent is too old	The Agent predates this feature	Update the JAMS Incident Connector on that server.
the job has no parameter named "…"	The name doesn't match a parameter on the job	Fix the spelling, or add the parameter to the job in JAMS and Validate again.
Retries must be a whole number (got "…")	The email gave a value of the wrong type	Adjust the value you pull out of the email, or the parameter's type.
ServerName is required and has no value	A required parameter got nothing	Give it a value, or a default in JAMS.
{{Server}} was not found in the email	The value couldn't be found in that email	Check the text after label against a real email, using Test with a sample email.
JAMS refused to submit …: access denied	The Agent's JAMS user lacks Submit access	Grant Submit on the job and its folder to the API token's user (or the Agent's legacy login).
JAMS created entry … but could not pass it to the JAMS Scheduler	Usually: after a reboot, the JAMS API service started before its database was ready. Less often: the JAMS API's Scheduler connector is missing.	Restart the JAMS API Windows service on the JAMS server, then try again. Delete the entry it names in the JAMS Monitor; it won't run. If a restart doesn't fix it, a JAMS administrator needs to add the JAMS API's Scheduler connector (WebClient).
No notice after the job failed	Alert the recipients if it fails is off, your JAMS Notification Job already alerted, or the flow is switched off	Check the setting; check the audit log for jams.submit.failed, which says why nobody was notified.
View Log: The JAMS Agent has not returned the log yet	The Agent is offline or busy	Check the JAMS Incident Connector service, then try again.
View Log: This server's Agent … is too old	The Agent predates job logs	Update the JAMS Incident Connector on the JAMS server.
Can't save, or Next is greyed out: JAMS requires … and the job has no default	A required parameter is empty	Enter a value for it, usually one of the placeholders.
JAMS rejected the API token	The token expired, was revoked, or belongs to another JAMS server	Create a new System API Token in JAMS and re-run the connector setup.
… path built from the email is outside the allowed folder	The email's value pointed somewhere else	Expected protection. Check the email, or widen Only inside if that job should be allowed.