Description:

The Execute Job step belongs to the Database category in FlowWright. Its XML definition identifies the step as executejob, with the label “Executes a Job” and display name “Execute Job.”

The step connects to a configured database and executes the job specified through the Variable/Global to enter the job name property. The job name can be supplied as a workflow variable or global variable, allowing the workflow to determine which database job should be executed at runtime.

Unlike the ExecuteSQL step, Execute Job does not require the workflow designer to provide the SQL statement itself. The database operation is encapsulated within the job, while FlowWright is responsible for invoking it.

Typical uses include:

• Triggering a predefined database job
• Reusing an existing database operation
• Starting database processing from a business workflow
• Keeping database implementation details outside the workflow
• Invoking standardized database processing from multiple workflows
• Triggering scheduled-style processing on demand
• Integrating database jobs with approvals or business events
• Executing database maintenance or processing operations as part of a workflow

The step provides True and False execution paths, allowing the workflow to continue differently depending on whether the job execution succeeds or fails.

Usage:

The Execute Job step is typically placed in a workflow when a business process needs to trigger a predefined database operation.

During execution:

1. Select the required Connection string.
2. Provide the Variable/Global to enter the job name.
3. Execute the step.
4. FlowWright connects to the configured database.
5. The specified database job is executed.
6. Continue workflow processing through the True or False path.

A typical workflow might look like:

Please refer to the SQL Server documentation for setting up a SQL job within Microsoft SQL Server: 

https://docs.microsoft.com/en-us/sql/ssms/agent/create-a-job?view=sql-server-2017#SSMSProcedure

Example:

Let’s build and execute the “executeJobDef” example.                            

• Create a new process definition named “executeJobDef” and open it in designer mode. 
• Drag an “executeJob” step to the canvas.
• Connect the dots between the “Start” step and “executeJob” steps, as shown above. 
• Click the “executeJob” step to configure its “Required” properties. Provide a name for the step. Select the connection string from the drop-down list. Provide a variable or global that contains the SQL job name, or enter the actual job name. Click the Save button. Note: Click the "AI Predict" button for the Copilot to add new process steps that match your process description. 

• The “Logging” configuration is necessary for documentation and also measures workflow progress and percent complete. This is achieved by configuring the step state and percent fields individually, as shown below. Configure the “Logging” using the following properties.

• Save the process definition, create an instance, and execute it. This step should perform the job on the selected database server.

Tips:

• Always configure the required Connection string and Variable/Global to enter the job name properties. 
• Ensure the configured connection points to the database containing the required job.
• Verify that the job name supplied by the workflow exactly identifies the intended database job.
• Use a workflow variable/global when the job needs to be selected dynamically.
• Prefer a predefined database job when the database operation is complex or reused by multiple workflows.
• Use the True path for successful job completion.
• Use the False path for error handling, logging, notification, or recovery processing.
• Avoid duplicating complex database logic inside multiple workflows when the operation can be encapsulated and reused as a job.
• Test the database job independently before integrating it into a production workflow.
• Ensure the FlowWright execution context has the required permissions to execute the database job.

Notes:

• Execute Job is a Database workflow step. 
• Its internal name is executejob. 
• Its label is “Executes a Job.” 
• Its display name is “Execute Job.” 
• The step has 2 input connections and 2 output connections. 
• Connection string is required. 
• Variable/Global to enter the job name is required. 
• The connection property uses the selectConnectString data type. 
• The job-name property uses the string data type. 
• The step provides True and False execution paths. 
• The XML does not expose SQL text, SQL parameters, result format, result-variable storage, command timeout, alternate database selection, or transaction configuration. These capabilities should therefore not be assumed to be part of Execute Job.

Execute Job vs. Execute SQL Statement:

Both steps belong to FlowWright's Database category, but they provide different levels of database control.

Execute SQL Statement directly executes SQL supplied by the workflow.

Execute Job invokes a predefined database job. The Execute Job XML exposes only Connection string and Variable/Global to enter the job name as configurable properties.

When to Use Execute Job

Use Execute Job when the database operation already exists as a predefined job, and the workflow only needs to invoke it.

Typical scenarios include:

• Triggering a predefined database job
• Reusing a common database operation
• Keeping database logic outside workflow definitions
• Standardizing database processing
• Invoking the same database operation from multiple workflows
• Dynamically selecting a job using a workflow variable/global

The main advantage is encapsulation: the workflow does not need to contain the SQL implementation of the operation.

When to Use Execute SQL

Use Execute SQL Statement when the workflow needs direct control over the database operation.

Typical scenarios include:

• Querying database information
• Inserting records
• Updating records
• Deleting records
• Executing parameterized SQL
• Retrieving database results
• Returning results to workflow variables
• Configuring command timeout
• Using transactions
• Executing against a different database

These capabilities are documented in the ExecuteSQL content page.

Key Distinction

The simplest way to distinguish the two steps is:

Execute Job: “Execute this named database job.”

Execute SQL Statement: “Execute this SQL statement against the database.”

In short:

• Use Execute Job for predefined, reusable database operations.
• Use Execute SQL Statement for direct and configurable SQL execution.
• Use Execute Job when the SQL/database implementation should remain encapsulated outside the workflow.
• Use Execute SQL when the workflow needs parameters, result handling, timeout control, database selection, or transaction configuration.
• Both steps provide True and False execution paths.

Definition Sample:

You may download the sample definition and later import it into the FlowWright Process Definition (XML file) page using drag-and-drop, following the same convention used in the ExecuteSQL documentation.

After importing the sample:

1. Verify the Connection string.
2. Verify the Variable/Global to enter the job name.
3. Confirm that the specified database job exists.
4. Verify the True and False workflow paths.
5. Save the process definition before creating a process instance.
6. Execute a test instance and verify the job execution result.

Click here to download the sample file.