Migration Guide: Migrating from Cases to Records

Overview

This guide outlines the changes related to workflow execution in the API and provides steps for adapting integrations accordingly.

Key Changes

Creating a Case is Now Optional

• Previously, running a workflow required associating it with a case.

• Now, workflows can be executed without creating a case.

• In the new API, creating a case is no longer necessary, and workflows can be executed independently.

Deprecation of Case API

• The API for creating cases will be marked as deprecated in favor of the new Records system.

• Workflows can still be run independently, even without using Records.

Running Workflows for Records

• A recordId can be provided to execute a workflow for a specific record.

• If recordId is omitted, workflows can create records dynamically if configured properly.

Important: recordId is optional unless you want to use our CRM system. If you wish to do so, please contact [e-mail] for configuration. Without this, you can still execute workflows and retrieve results as usual.

API Changes

Changelog 2025-02-13

Migration Steps

When making API requests, ensure that you send the header Accept: application/json;version=2 to use new endpoints.

1. Update Workflow Execution

Changes:

• Old: POST /workflows/run (uses caseId)

• New: POST /workflows/run (uses recordId)

Migration Steps:

• Replace caseId with recordId in the request payload.

• Ensure that the correct recordId is passed when applicable.

• If no recordId is given, workflows will execute normally.

2. Update Workflow Status Retrieval

Changes:

• Old: GET /workflows/{workflowId} returns caseId.

• New: GET /workflows/{workflowId} returns recordId

Migration Steps:

• Modify your integration to use recordId instead of caseId in the response when applicable.

• Ensure that any business logic that depends on caseId is updated accordingly.

3. Update Workflow Result Retrieval

Changes:

• Old: GET /case/{caseId} returns case-based data (deprecated).

• New: GET /workflows/{workflowId}/result returns workflow-based data.

• The response structure remains the same.

Steps:

• Update all API references from /case/{caseId} to /workflows/{workflowId}/result.

• Ensure that workflows are correctly mapped to their corresponding workflowId.

4. Update Token Generation

Changes:

• Old: POST /token (uses caseId).

• New: POST /token (uses recordId).

Steps:

• Replace caseId with recordId in the token generation request.

• Ensure that the correct recordId is passed when applicable.

5. Update Link Generation

Changes:

• Old: POST /link and POST /link/send (uses caseId).

• New: POST /link and POST /link/send (uses recordId and requires email in POST /link/send).

Steps:

• Replace caseId with recordId in link generation requests.

• Ensure that the correct recordId is passed when applicable.

• Ensure that email is included in POST /link/send requests.

Frequently Asked Questions (FAQ)

1. Do I need to use recordId for all workflows?

No, recordId is optional unless you are using our CRM system. Workflows can still be executed without it.

2. What should I do if I used the /cases/{caseId} endpoint to retrieve the process result?

You have two options:

1. Migrate to the record-based functionality by updating your workflow to use recordId instead of caseId. This may require modifying workflows to ensure compatibility with the new Records system.

2. Use the /workflows/{workflowId}/result endpoint to retrieve workflow results instead of /case/{caseId}.

3. Can I still use the caseId parameter?

No, caseId is deprecated. You must switch to using recordId instead.

4. What should I do if my integration depends on caseId?

Update all references to caseId and replace them with recordId. Ensure that workflows function correctly with the updated API.

For further assistance, contact our support team at [e-mail]