Service Tasks vs. Scripted Runs

BCCL offers two ways to run operations unattended: Service Tasks dispatched from Business Central to a BCCL agent, and scripts of BCCL command lines scheduled with Windows Task Scheduler. This page explains which model fits which workload, so you pick the right one before you build dozens of tasks.

The Short Answer

Service Tasks are intended primarily for one-off and ad-hoc operations started from the Business Central user interface, and for a limited, manually maintained set of recurring tasks.
Scripts + Windows Task Scheduler are the recommended model when you need to move many tables, replicate the same set of tables across many companies, or run continuous SQL synchronisation.

If you find yourself about to create one Service Task per table per company, stop and write a script instead.

Why Service Tasks Do Not Scale to Bulk Work

Service Tasks are a convenient user interface over BCCL, but several properties make them the wrong tool for large replication sets:

Property	Consequence
One Service Task covers one table	Replicating 100 tables means 100 tasks; across five companies, 500 tasks.
One agent executes one task at a time	Tasks queued for the same agent run sequentially. A multi-table sync built from Service Tasks is serialised unless you install more agents.
Tasks are created and maintained individually	There is no bulk-create, no duplicate-to-other-company action, and no spreadsheet or file import/export of Service Task definitions.
Task IDs are short	The practical Task ID limit is 20 characters (see Naming Service Tasks below). Per-company plus per-table naming schemes run out of room quickly.

None of these are defects. They follow from the design goal of Service Tasks: letting a Business Central user trigger and monitor a specific operation without touching a command line.

The Recommended Model for Bulk Work

For scenarios such as exporting a large set of tables from several Business Central companies to an on-premises SQL Server (a typical shape is roughly 20 central, company-independent tables plus roughly 100 company-specific tables, repeated across several companies), hougaard.com support recommends:

Create a .bat / .cmd script containing one BCCL command line per table (and per company).
Schedule the script with Windows Task Scheduler.
Use the mapping files and scripts generated by the SQL Bundle Builder as your starting point. The bundle already contains FirstRunBCCL.cmd (initial full load) and RunBCCL.cmd (incremental sync), which is exactly the recommended pattern for multi-table SQL replication.

Scripts are the tool for programmatically iterating over many tables and looping over companies. A script line is cheap to add, copy, or comment out, and the whole set can be kept under version control.

You Do Not Need Service Mode for Scripts

If all your replication runs from scheduled scripts, BCCL does not need to run as a Windows service. Command-line mode is sufficient, and no bccl_service.json file is required. Service mode is only needed if you want Business Central users to dispatch Service Tasks to an agent.

Running Both Models on One Machine

You can run both models side by side. The rule that decides the mode is simple: if a file named bccl_service.json exists in the same folder as BCCL.EXE, BCCL starts in service mode.

To use both on the same server:

Install BCCL.EXE into two separate folders, for example C:\BCCL\Service&#; and C:\BCCL\Scripts&#;.
Place bccl_service.json only in the folder that should act as the service agent, and install that copy as the Windows service.
Run the scheduled scripts from the other folder, which has no bccl_service.json.

If a scheduled command is started from a folder that contains bccl_service.json, BCCL enters service mode instead of executing the command and the command prompt never returns. See Service Installation Overview.

Choosing a Model

Workload	Recommended model
A single ad-hoc export, import, or delete	Service Task
An operation a Business Central user must be able to trigger without command-line access	Service Task
A small number of recurring tasks managed and monitored inside Business Central	Service Task (Automation + Job Queue)
A near-real-time, agent-driven run for one or a few tables	Service Task (Automation + Job Queue)
Many tables	Scripts + Windows Task Scheduler
The same tables replicated across many companies	Scripts + Windows Task Scheduler
Large scheduled SQL replication batches	Scripts + Windows Task Scheduler (SQL Bundle Builder scripts)
Continuous table synchronisation to SQL Server	Scripts + Windows Task Scheduler

Service Task Automations Remain Useful

Automations scheduled with the Business Central Job Queue are still available and useful when you specifically want everything managed inside Business Central. Keep the constraints in mind: one task equals one table, and one agent executes only one task at a time. High table counts or short intervals therefore require multiple agents, each in its own folder with its own bccl_service.json and unique agentid. See Automations and Scheduling.

Naming Service Tasks

The Task ID field is stored as a 50-character code, but two other limits apply in practice:

The Service Task Card truncates any Task ID longer than 30 characters when you enter it.
The Service Task Log stores Task IDs in a 20-character field.

Treat 20 characters as the practical limit for a Task ID. If the task will be used as an Automation template, the clone suffix (-000000001) consumes 10 additional characters, so keep template IDs to 10 characters or fewer.

Practical consequences:

Task IDs must be unique, so a per-company plus per-table scheme such as <CompanyPrefix> <TableName> quickly exceeds the available characters. Use short company abbreviations rather than full company names.
Task lists sort alphabetically, so a consistent prefix groups related tasks together.
If your naming scheme does not fit inside the Task ID limit because you have many tables or companies, that is itself a signal to use the scripted Task Scheduler approach described on this page.

See Creating Service Tasks for the field reference.

Example: From Service Tasks to a Script

Suppose you have created Service Tasks for Location (table 14), Dimension Value (table 349), and Production Order (table 5405) in one company and now need the same for eight more companies. Instead of creating 24 more tasks, write one script per company:

@echo off
REM Company A - company-specific tables
SET WS=https://api.businesscentral.dynamics.com/v2.0/<tenant-id>/<environment>/WS/<company-a>/Codeunit/bccl
SET AUTH=--auth S2S --clientid <client-id> --clientsecret "<client-secret>" --tenantid <tenant-id>
SET SQL=--sqlconnect "Server=<server>;Database=<database>;User ID=<user>;Password=<password>"

BCCL -w "%WS%" %AUTH% -t getdata -s table=14   -f sql -o "[CompanyA$Location]"         -m mapping\Location.mapping.json %SQL%
BCCL -w "%WS%" %AUTH% -t getdata -s table=349  -f sql -o "[CompanyA$Dimension Value]"  -m mapping\DimensionValue.mapping.json %SQL%
BCCL -w "%WS%" %AUTH% -t getdata -s table=5405 -f sql -o "[CompanyA$Production Order]" -m mapping\ProductionOrder.mapping.json %SQL%

Copy the script for each company, change the company segment of the web service URL and the -o target table names, and schedule the scripts with Windows Task Scheduler. All parameters, including authentication, are on each command line; --remember is not used. See Replicating Multiple Companies for the complete pattern, and Generating Scripts for the Request Builder's script bundles.

Frequently Asked Question

Can I export my Service Tasks to Excel or a file, change the company name, and import them into other companies so I do not have to create them one by one?

No. There is no supported export/import of Service Tasks for that purpose. For work that has to be repeated across many tables or many companies, use a script instead of Service Tasks, as described on this page.

Tips and Best Practices

Decide the model before you start creating tasks. Converting a large set of Service Tasks into a script later means re-entering every table and filter.
Start from the SQL Bundle Builder output for SQL replication; it already generates the script pattern and mapping files you need.
Keep the service-mode folder and the script folder separate so a scheduled command never picks up bccl_service.json by accident.
Use Service Tasks for what they are good at: letting Business Central users run and monitor a specific operation on demand.
Use Service-to-Service authentication and put every parameter on one command line in scheduled scripts. See Running Long or Unattended Transfers Reliably.