Transfer Activities to Queue
Overview
This API can be used by the logged in user to transfer specific activities to a target queue.
Activities to be transferred can belong to a single case or multiple cases.
For this API to execute successfully:
- All activities must exist in the application.
- The activities must be of type Email. Calltrack and Chat type of activities cannot be transferred to a queue.
- For Email type of activities, only inbound or composed activities can be transferred.
- The status of all activities in the request must be either "in queue waiting to be assigned" or "assigned to a user".
- If status of an activity is "assigned to a user" then:
-
If the activity is assigned to a user other than the logged in user, activity must not be locked by the user.
-
If the activity is pinned by the user, the query parameter "unpin" must be sent with a value of "yes".
- Activities in status "in queue waiting to be assigned" must not belong to the target queue.
- All activities must belong to the same department as that of the queue.
- No more than 75 activities must be sent in one request.
- The target queue must be active.
As part of completing this API request:
- Any draft replies created for incoming email activities will also be transferred along with the original activity.
- Since
- 11.6
APIs
| Method | URL | Description |
| PUT | /ws/v12/interaction/activity/transfer?queue={ID} | Transfer one or more activities to a queue. |
Authentication
Authentication is required. The client must be logged in to call this API. Each API request must contain X-egain-session request header returned by Login API.
Permissions
All of the following are required:
- The logged in user must have transfer permission on the target queue.
- All the activities must either belong to the home department of the logged in user, or to a department in which the user is a foreign user.
- If activity is not assigned to the logged in user, the logged in user must have the permissions as required by Pick Activities API. Refer Permissions section for details.
Licenses
The logged in user must have the following licenses:
- Any User Licenses
- If activity is not assigned to the logged in user, the logged in user must have the licenses as required by Pick Activities API. Refer Licenses section for details.
Request
Request headers
| Name | Description | Allowed values | Default value |
| X-egain-session | Session ID obtained from Login API response header | N/A | N/A |
| Accept | Content type accepted by client. | application/xml or application/json | N/A |
| Content-Type | Media type sent by the client | application/xml or application/json | N/A |
| Accept-Language | Language locale accepted by client (used for locale specific fields in resource representation and in error responses) | Supported 'Accept-Language' header codes | default system language |
Request Body
The request body is mandatory and can be in either XML or JSON format.
Elements required in the request body
'activities' element must be present in the request body. At least one 'activity' element must be present in the 'activities' element. Each 'activity' element must contain the following elements:
| Name | Description |
| id | ID of the activity to be transferred |
| lastModified.date | Value of last modified date of the activity |
Optional elements allowed in the request body
None
Request body XML schemas:
- schema-interaction-activity-Activity
Supported API specific query parameters
Query parameters required in the request
- queue: ID of the queue to which the activities should be transferred. This must be an existing queue.
Query parameters allowed in the request
- unpin: The only value allowed for this query parameter is "yes". This is required to transfer activities even if they are pinned by a user. If any of the activities is pinned by a user and the "unpin" query parameter is not provided in the request, the request will fail.
- reassign: The only value allowed for this query parameter is "yes". This parameter indicates whether the activities being transferred can be reassigned to the logged in user by application. If the parameter is not provided, the system will not reassign the transferred activity to the logged in user.
Supported common query parameters
None
Response
Response headers
| Name | Description | Possible values |
| X-egain-session | ID of the current user session | N/A |
| Content-Type | Media type of response body | application/xml or application/json |
Response body
The response body will be sent only in case of error. It can be in either XML or JSON format.
Response body XML schemas:
- schema-kb-WSError - used in case of error
HTTP status codes
Success Status codes
204 - No Content
- Successfully transferred the requested activities.
Failure Status codes
400 - Bad Request
- Unsupported query parameter is sent in the request.
- Unsupported query parameter value is sent in the request.
- Required API specific query parameters are not provided.
- Request body does not contain the required elements.
- Unsupported element is present in the request body.
- Any criteria for successful execution mentioned in the Overview or Request Body sections are violated (except when activity is locked, which will result in 403-Forbidden).
401 - Unauthorized
- X-egain-session request header is missing.
- Session is invalid or expired.
403 - Forbidden
- The user does not have sufficient permissions. Refer the Permissions section for details.
- One or more activities sent in the request are locked by another user.
406 - Not Acceptable
- Invalid 'Accept-Language' header value.
409 - Conflict
- The lastModified date of any activity in the request does not match its lastModified date on the server.
500 - Internal server error
Examples:
Example 1 - Transfer an activity to queue
Example 2 - Transfer multiple activities to a queue
