Learn when to use a connector or a custom worker, and design safe input, secrets, retries, and outcomes for external systems.
Built-in connectors speed up common integrations, while a custom connector or job worker can encapsulate a specialized protocol or substantial business logic. Choose based on operational ownership and testability, not only initial setup time.
Try it: Compare a simple outbound REST notification with a multi-step legacy-system update. Explain which one you would implement as a connector and which might justify a worker.Document which fields leave the process, where authentication is configured, and what result data returns. Do not place secrets in BPMN properties or a public example; use the platform's supported secret management.
Try it: Review a sample connector request and remove personal data that is unnecessary for the external service.A transient outage, invalid request, and business decline require different outcomes. Retry only where the operation can safely repeat or has an idempotency strategy.
Try it: Create a failure table for a shipping API: 503 outage, invalid address, and duplicate booking. Define the expected process route for each.A built-in connector offers a reusable, configured way to call a supported service from a BPMN task. A custom job worker gives application code more control over a specialized protocol, multi-step operation, or domain-specific error handling. Neither choice removes the need to know where the task runs, how credentials are supplied, and who can observe failures. Use a connector for a straightforward supported call only after checking its current inputs and error behavior. Prefer a worker when integration logic needs substantial code, custom tests, or a team-owned deployment lifecycle.
Try it: Compare sending a standard notification with reserving inventory in a legacy system. For each, record integration type, operation owner, retry policy, observability, and how it will be tested.A process can carry values between tasks, but each integration should receive only the fields it needs and return an explicitly named result. Broadly passing a customer object makes later changes and data-protection review harder; returning a raw API response can bind process logic to an external schema. Create an input mapping for stable business identifiers and necessary parameters, then map the response to a small outcome contract. Decide whether error details belong in process variables, an incident message, or secured application logs. Camunda documents connector configuration and secrets separately; do not put a live token into BPMN properties or examples.
Try it: For a fraud-check call, reduce a hypothetical 20-field customer record to necessary inputs, name the three possible outputs, and document where diagnostic details will be stored.An unavailable service may recover, but a retry may reach a service that already completed the first request before the response was lost. Payment, fulfilment, and notification calls therefore need a stable operation identifier and a downstream duplicate-handling rule where possible. Simulate a response timeout after a successful side effect, not only a connection failure before work begins. If the service cannot be made idempotent, document the reconciliation or human-review step rather than claiming that a retry is automatically safe. A business rejection should take an explicit route instead of being retried as a technical outage.
Try it: For a booking API, describe the result when the initial call succeeds but its response is lost. Test a second call with the same identifier and explain how the process avoids a double booking.This topic is an independent ITCertPath learning guide, not a separately named Camunda credential. Check current product behavior in the official documentation.
Read the official Camunda documentation ↗Tell us your goal, country and preferred schedule. Ask for the written syllabus, trainer, delivery format, fee and cancellation terms before enrolling.