ConnectCases / Client / start_merge_cases

start_merge_cases

ConnectCases.Client.start_merge_cases(**kwargs)

Merges a secondary case into a primary case. The primary case, which you specify in the request URI, remains active. Both cases must belong to the same domain.

The merge runs asynchronously. To track its progress, call GetMergeCasesStatus. When the merge finishes, the selected field values and related items from the secondary case are on the primary case, the two cases are linked, and the secondary case is closed. Both cases record the merge in their audit history. For more information, see GetCaseAuditEvents.

Important things to know

  • Both cases must have the same customer, or at least one of them must have no customer.

  • While the merge runs, you can’t modify the secondary case or its related items, and you can’t delete the primary case. These requests return a ConflictException.

  • After the merge, the secondary case can be reopened, updated, and deleted, but it can’t be merged again.

The request fails with a ValidationException, and no merge starts, if:

  • The primary case and the secondary case are the same case.

  • Either case is closed.

  • Both cases have a customer, and the customers are different.

  • fieldsConfiguration selects a field that can’t be merged, or a field that the secondary case doesn’t have.

  • After the merge, the primary case would have more than 500 field values, or would exceed the maximum case size.

The request fails with a ServiceQuotaExceededException if, after the merge, either case would exceed the quota for related items per case. For the primary case, the count is its existing related items, plus the related items moved from the secondary case, plus the new case link. See Connect Customer Cases quotas.

The request fails with a ConflictException if either case is already part of a merge that is running, or was previously merged into another case as the secondary case.

Endpoints: See Connect Customer endpoints and quotas.

See also: AWS API Documentation

Request Syntax

response = client.start_merge_cases(
    domainId='string',
    caseId='string',
    secondaryCaseIds=[
        'string',
    ],
    fieldsConfiguration=[
        {
            'fieldIds': [
                {
                    'id': 'string'
                },
            ],
            'sourceCaseId': 'string'
        },
    ],
    relatedItemsConfiguration={
        'comment': True|False,
        'connectCase': True|False,
        'contact': True|False,
        'custom': True|False
    },
    performedBy={
        'userArn': 'string',
        'customEntity': 'string'
    }
)
Parameters:

  • domainId (string) –

    [REQUIRED]

    The unique identifier of the Cases domain.

  • caseId (string) –

    [REQUIRED]

    The unique identifier of the primary case. The primary case remains active and receives the merged field values and related items. The cases can use different templates, and the primary case keeps its template.

  • secondaryCaseIds (list) –

    [REQUIRED]

    The unique identifier of the secondary case to merge into the primary case. The secondary case is closed when the merge finishes. Specify exactly one case ID.

    • (string) –

  • fieldsConfiguration (list) –

    The fields whose values to take from the secondary case. You can only merge custom fields and the following system fields: assigned_queue, assigned_user, summary, and case_reason. If you select any other system field, the request fails with a ValidationException.

    For each field that can be merged, the merge works as follows:

    • If you select the field, the primary case gets the secondary case’s value. If the secondary case’s value is empty, the primary case’s value is cleared.

    • If you don’t select the field and the primary case has a value for it, the primary case keeps its value.

    • If you don’t select the field and the primary case doesn’t have the field, or its value is empty, the primary case gets the secondary case’s value. This applies even when the field isn’t on the primary case’s template.

    Field values are read from both cases when the merge runs, so changes that you make to the primary case after you start the merge are taken into account.

    Specify at most one entry, and set its sourceCaseId to the secondary case ID.

    • (dict) –

      Specifies the fields whose values to take from the secondary case when you merge cases.

      • fieldIds (list) – [REQUIRED]

        The fields whose values to take from the source case. Each field must exist on the source case and must be a field that can be merged. Don’t list the same field more than once.

        • (dict) –

          Object for unique identifier of a field.

          • id (string) – [REQUIRED]

            Unique identifier of a field.

      • sourceCaseId (string) – [REQUIRED]

        The unique identifier of the case to take the field values from. This must be the secondary case.

  • relatedItemsConfiguration (dict) –

    The types of related items to move from the secondary case to the primary case. Related items of a type that you don’t select, or set to false, stay on the closed secondary case. If you omit this parameter, no related items are moved.

    File, SLA, and work plan related items are never moved. They stay on the secondary case.

    • comment (boolean) –

      Whether to move Comment related items to the primary case.

    • connectCase (boolean) –

      Whether to move Case related items to the primary case. If the primary case already links to the same case, the secondary case’s link is removed instead of moved.

    • contact (boolean) –

      Whether to move Contact related items to the primary case. If the same contact is related to both cases, the primary case keeps its related item and gets any tag keys that only the secondary case’s related item has.

    • custom (boolean) –

      Whether to move Custom related items to the primary case.

  • performedBy (dict) –

    The user who performed the merge. If you provide userArn, you must also have DescribeUser permission on the ARN of that user.

    Note

    This is a Tagged Union structure. Only one of the following top level keys can be set: userArn, customEntity.

    • userArn (string) –

      Represents the Connect Customer ARN of the user.

    • customEntity (string) –

      Any provided entity.

Return type:

dict

Returns:

Response Syntax

{}

Response Structure

  • (dict) –

Exceptions