Examples of Queries and Mutations in the API Explorer

  57 minute read  

Retrieve data using queries

You can retrieve data in a portal using the Connect API by executing a query operation.

A GraphQL query returns only the data that you specify in the query. To structure a query, you specify the objects and fields that you want to return. You must nest fields within a query until all fields return scalars. A scalar is concrete data, such as the name of a user.

Queries have the following structure:

Sample query structure:

query MySampleQuery {
  JSON objects to return
}

Optionally, you can include a unique name for each query, such as query yourQueryName { }.

Note: GraphQL syntax is case-sensitive.

Modify data using mutations

You can also modify data in a portal using the Connect API by executing a mutation operation.

To perform a mutation, you must specify the following information:

• Mutation name: The type of modification you want to perform.
• Input fields: The data that you want to send to the server. You pass the input fields as an argument to the mutation name. In the reference documentation, an exclamation mark (!) indicates a required field in an argument.
• Payload fields: The data that you want to return from the server. You pass the payload fields in the body of the mutation name.

Mutations have the following structure:

Sample mutation structure:

mutation MySampleMutation {
  mutationName(inputArgumentKey: {MutationNameInputFields!}) {
    MutationNamePayloadFields
}

If a mutation returns an object type as part of the payload, you can ask for nested fields of that object. This can be useful if you want to determine information about an object after you update the object.

Sometimes, mutations require you to pass information that you cannot figure out without running a query. For example, to add an annotation to a document, you must provide the page ID as an argument in the mutation. You can run a query first to determine the required information, and then perform a mutation using the returned data in the query.

Only an API user can copy their own token

If a user has authorization to use the API, only that user can copy their API token.

The API Access page displays the API token and API key as well as links to copy the token and key. Previously, the API Access page was available in the Portal Management > User Administration page.

Note: The API Access page is visible only if a user is authorized to use the API.

To access the API Access page, on the Portal Home page, from the user name menu, select Account Settings. On the Account Settings page, in the navigation pane, select API Access.

Sample Queries

General Information

Query users and their groups within cases

API queries can pull information on users and their groups within cases to help manage users and groups across review platforms. You can filter and sort the group data by name, id or userCount for NumericComparison. You can also separate the query results by page by using the standard_scroll_parameter (for example, scroll: \{start: 1, limit: 100} ).

Note: To return the users of a specific group, add the user’s node under groups.

The following lists the available fields for querying user and group data:

• groups: Object to extract the following field data:

• id

• name

• userCount

• timelineDate

• quickCode

• startPage

• users

Sample query:

query MySampleQuery {
  cases(id:5){
    name
    groups (id: 17 name: “group name” sort: [{ field: name, dir: Asc }]) {
      id
      name
      userCount
      users {
        id
        userName
      }
    }
  }
}

Sample results:

{
  “data”: {
    “cases”: [
      {
        “name”: “Clean_Enron”,
        “groups”: []
      }
    ]
  }
}

Request data about user-defined pick list fields

The {cases {fields}} query now supports user-defined pick list fields as filter criteria and returns user-defined pick list fields as responses. The count is the number of documents coded to the field value.

Sample query:

query MySampleQuery {
  cases {
    fields(name:“Relevance”) {
      name
      items {
        name
        count
      }
    }
  }
}

Sample results:

{
  “data”: {
    “cases”: [
      {
        “fields”: [
          {
            “name”: “Relevance”,
            “items”: [
              {
                “name”: “Coded”,
                “count”: 1
              },
              {
                “name”: “Not coded”,
                “count”: 1885514
              }
            ]
          }
        ]
      }
    ]
  ]
}

Binders

Request data about binders in a case

You can request data about the binders in a case using the cases {binders} object.

Sample query:

query MySampleQuery {
  cases {
    binders {
      id
      name
      count
      documents {
        id
      }
      type
      securityOverride
      owner {
        fullName
      }
      creator {
        fullName
      }
      createdDate
      lastUpdated
    }
  }
}

Sample results:

{
  “data”: {
    “cases”: [
      {
        “binders”: [
          {
            “id”: 43412,
            “name”: “! Mass code Testing”,
            “count”: 0,
            “documents”: [],
            “type”: “Shared”,
            “securityOverride”: false,
            “owner”: null,
            “creator”: {
              “fullName”: “Kang, Heman”
            },
            “createdDate”: “2020-05-27T21:51:34.573Z”,
            “lastUpdated”: null
          }
        }
      }
    }
  ]
}

You can include the following arguments in the binders object:

• id
• name
• type
• scroll

Blocked Changes

Request data about blocked changes to document files

The fileChangesBlockedBy field in the cases{documents} object returns an enumerated value to indicate blocked changes to document pages by Annotations, or locked Productions not printed.

A case administrator must request the information. The mutation returns blank values if document permissions allow changes.

Sample query:

query MySampleQuery {
  cases(id: 5) {
    documents(mainIds: [400, 401, 402]) {
      documentId
      fileChangesBlockedBy
    }
  }
}

Sample results:

{
  “data”: {
    “cases”: [
      {
        “documents”: [
          {
            “documentId”: “Enron_000002352”,
            “fileChangesBlockedBy”: []
          },
          {
            “documentId”: “Enron_000002357”,
            “fileChangesBlockedBy”: []
          },
          {
            “documentId”: “Enron_000002359”,
            “fileChangesBlockedBy”: []
          }
        ]
      }
    ]
  }
}

Case Decommission Status

Request the decommission status of cases

Use the decommissionStatus field to request the decommission status for a case.

• All returns the decommissioned status for all cases.
• Deleted identifies deleted decommissioned cases.
• Archived identifies archived decommissioned cases.
• Live identifies active or inactive non decommissioned cases.

The following sample query returns the name and decommission status of all cases in the portal.

Sample query:

query MySampleQuery {
  cases {
    name
    decommissionStatus
  }
}

Sample results:

{
  “data”: {
    “cases”: [
      {
        “name”: “1_Acme6_PM2”,
        “decommissionStatus”: “Live”
      }
    ]
  }
}

After decommissioning a case, you can use the cases query to get data about deleted cases such as the case creation date, decommission date, status, and user, as shown in the following example.

Sample query:

query MySampleQuery {
  cases(decommissionStatus:Deleted) {
    name
    active
    caseCreatedDate
    decommissionStatus
    caseDecommissionedBy
    caseDecommissionedDate
  }
}

Sample results:

{
  “data”: {
    “cases”: [
      {
        “name”: “A6clone”,
        “active”: false,
        “caseCreatedDate”: “2020-03-31T12:02:10.587Z”,
        “decommissionStatus”: “Deleted”,
        “caseDecommissionedBy”: “Buckholt, Aric”,
        “caseDecommissionedDate”: “2020-03-31T12:06:01.217Z”
      }
    ]
  }
}

Identify archived cases using the decommissionStatus field

In the Connect API Explorer, the decommissionStatusEnumType filter now includes the status Archived as a value by using the decommissionStatus field.

Sample query:

query MySampleQuery {
  cases (decommissionStatus: Archived) {
    name
    caseDecommissionedBy
    caseDecommissionedDate
    decommissionStatus
  }
}

Sample results:

{
  “data”: {
    “cases”: [
      {
        “name”: “Acme”,
        “caseDecommissionedBy”: “Doe, John”,
        “caseDecommissionedDate”: “2020-06-15T18:35:55.743Z”,
        “decommissionStatus”: “Archived”
      }
    ]
  }
}

Coding

Updates to the Case field objects

This release includes the following updates to fields for the Case field objects:

• Case:

• To return the date that inactive cases were last active, you can now query the {cases {lastActive}} field. This returns a null value for active cases.

• To return information about the dates that metrics on the Portal Management Reports are available for, you can now query the cases {statistics {metricsAvailability}} field. The metricsAvailability field returns the same value that appears when you hover over a calendar icon on the Portal Management Reports page.

Updates to the Organization field objects

This release includes the following updates to fields for the Organization field objects:

• Organization:

• The organizations {accountNumber} field now returns the account number that appears on the Portal Management > Organizations > Properties page.

• The providerOrganizationId. field replaces the previous organizations {parentOrganizationId} field name.

• To return the name of the provider organization for a client organization, you can now query the organizations {providerOrganizationName} field.

Updates to the RPF field objects

This release includes the following updates to fields for the RPF field objects:

• RPF:

When you filter an {rpf {jobs}} query with jobs(categoryName:“Name of a job typeem>”), The application now returns correct results for the specified job type.

Updates to the Case{field} field object

This release includes the following updates to the cases {field} field:

• The entityId field replaces the previous cases {fields {entity}} field name.
• You can now filter the cases {fields} field by id and entityId. The entity ID value for documents is 1.
• The cases {fields} field includes fields for id and entityId. The value for id maps to the value for composite_id, which is a combination of the field_id and ringtail_type_id fields from the sf_field table in the case database.
• To return the field type, you can now query the cases {fields {type}} field.
• To return the ID numbers of items in pick lists, you can now query the cases {fields {items {id}}} field.

Updates to the Cases{documentLoads} field object

This release includes the following updates to the cases {documentLoads} object:

• The cases {documentLoads {jobType}} field is now named type.

• To return the job ID for ingestions and import jobs, you can query the cases {documentLoads { id}} field.

• To return the Processing Framework (RPF) job ID for a job, you can query the cases {documentLoads { rpfJobId}} field.

• You can filter the cases {documentLoads} object by id, type, and status.

• The cases {documentLoads} object now returns the following types of ingestions jobs:

• Ingestions jobs with the status “Completed with Exceptions.”

• Ingestions jobs in which no documents were added to the application because all the documents in the job were suppressed as duplicates.

Case Statistics

Request data about the custom case statistics

You can request data about the custom statistics in a case by querying the cases {statistics {customStatistics}} field. To return the most up-to-date values in a case, before you perform the query, you must run a case metrics job or an indexing and enrichment job with the “gather case metrics” option selected.

Sample query:

query MySampleQuery {
  cases(id: 1) {
    statistics {
      customStatistics {
        name
        id
        value
        extension {
          id
        }
      }
    }
  }
}

Sample results:

{
  “data”: {
    “cases”: [
      {
        “statistics”: {
          “customStatistics”: [
            {
              “name”: “count_of_files___IngestAssistance”,
              “id”: 10000,
              “value”: 0,
              “extension”: null
            },
            {
              “name”: “size_of_files___IngestAssistance”,
              “id”: 10001,
              “value”: 0,
              “extension”: null
            },
            {
              “name”: “XLerator_Documents Processed”,
              “id”: 10002,
              “value”: 0,
              “extension”: {
                “id”: 8
              }
            },
            {
              “name”: “XLerator_Documents Printed”,
              “id”: 10003,
              “value”: 0,
              “extension”: null
            }
          ]
        }
      }
    ]
  }
}

caseProcs and caseProcParams objects for passing case parameters

The caseProcs and caseProcParams objects allows users to query a cases procedures and parameters data. This data allows the use of the caseProc object in a mutation for passing a procedure to the case database.

A user would first need to return the procedure name using the caseProcs object, as shown in the following example.

Required fields:

• caseId
• name
• procName

Optional fields:

• procOwner
• procExample
• procHelp

The following query sample filters on one specific case ID, and retrieves the cases procedure values, which includes the needed procName.

Sample query:

query MySampleQuery {
  cases(id: 5) {
    id
    name
    caseProcs {
      procName
      procOwner
      procExample
      procHelp
    }
  }
}

Sample results:

{
  “data”: {
    “cases”: [
      {
        “id”: 5,
        “name”: “Clean_Enron”,
        “caseProcs”: [
          {
            “procName”: “rp_proc_runner_example”,
            “procOwner”: “dbo”,
            “procExample”: “\r\nmutation PropertyInsertExample {\r\n  caseProc(caseId: 1018, procedure: \”rp_proc_runner_example\“, parameters: \”{\\\“user_id\\\”:\\\“1\\\”}\“) {\r\n    result\r\n  }}\r\n”,
            “procHelp”: “\r\n\t @user_id = null --pass in user id to restrict results to only what that user has access to”
          }
        ]
      }
    ]
  }
}

From the results of the caseProc search, the user can then run another query using the caseProcParams object for retrieving the cases parameters for use in the mutation, if needed.

Required fields:

• caseId
• name
• procedure

Optional fields:

• isOutPut
• paramName
• paramOrder
• paramPrecision
• paramScale
• paramType

Sample query:

The following query sample filters on one specific case ID and retrieves the cases parameter values using the procName retrieved from the previous query example.

Sample query:

query MySampleQuery {
  cases(id: 5) {
    id
    name
    caseProcParams(procedure: “rp_proc_runner_example”) {
      paramName
      paramOrder
      paramPrecision
      paramScale
      paramType
      isOutput
    }
  }
}

Sample results:

{
  “data”: {
    “cases”: [
      {
        “id”: 5,
        “name”: “Clean_Enron”,
        “caseProcParams”: [
          {
            “paramName”: “user_id”,
            “paramOrder”: 1,
            “paramPrecision”: 10,
            “paramScale”: 0,
            “paramType”: “int”,
            “isOutput”: false
          }
        ]
      }
    ]
  }
}

From the above query results, the user can now pass a procedure to the case database using the caseProc in a mutation, as shown in the following example.

Required fields:

• caseId
• procedure
• result

Sample mutation:

mutation MySampleMutation {
  caseProc(caseId: 5, procedure: “rp_proc_runner_example”) {
    result
  }
}

Sample results:

{
  “data”: {
    “caseProc”: {
      “result”: “{ \”outparams\“: [{}],\”datasets\“: {\”Table\“:[{\”doc_id\“:null,\”mainDate\“:null}],\”Table1\“:[{\”doc_id\“:null,\”thetext\“:null,\”text_type\“:null}]} }”
    }
  }
}

Data Models

Request information about Entity items

You can now use an entity ID to query for information about entity items within a data model, for example, the item name and item ID.

Sample query:

query MySampleQuery {
  cases(name: “Clean_Enron”) {
    dataModels {
      entities {
        items(id: 2069) {
          id
          itemId
          name
        }
      }
    }
  }
}

Sample results:

{
  “data”: {
    “cases”: [
      {
        “dataModels”: [
          {
            “entities”: [
              {
                “items”: [
                  {
                    “id”: 2069,
                    “itemId”: “Enron_000005822”,
                    “name”: “DOC-000491362.mht”
                  }
                ]
              }
            ]
          }
        ]
      }
    ]
  }
}

Ingestions

Generate a load report of imports and ingestions by case

You can request data about imports and ingestions using the cases {documentLoads} field.

Sample query:

query MySampleQuery {
  cases(id: 5) {
    documentLoads(
      startDate: 
      {
        value: “2018-01-01”,
        comparison: GreaterThan
      }, 
      endDate: 
      {
        value: “2020-01-31”,
        comparison: LessThan
      }
    ) 
    {
      name
      type
      firstLoadPath
      lastLoadPath
      documentCount
      jobStart
      status
      duration
      user {
        fullName
      }
    }
  }
}

Sample results:

{
  “data”: {
    “cases”: [
      {
        “documentLoads”: [
          {
            “name”: “EDRM File Format Data Set”,
            “type”: “Ingestions”,
            “firstLoadPath”: “EDRM File Format Dat\\data-set”,
            “lastLoadPath”: “EDRM File Format Dat\\data-set”,
            “documentCount”: 2385,
            “jobStart”: “2018-02-23T21:52:16.307Z”,
            “status”: “Completed with Exceptions”,
            “duration”: “1810”,
            “user”: {
              “fullName”: “Kang, He”
            }
          }
        ]
      }
    ]
  }
}

Metrics

Gathering data on folder size in file transfer

You can use the following fields in the cases {statistics} object to gather information about the size of folders in the file transfer and archive repositories.

• sizeOfArchiveFolderData is the total size of all archive files for a case in the Archive file repository.
• For file transfer repositories, use the sizeOfFileTransferData_<_foldername_> field, where _foldername_ is the name of the folder on the file transfer repository. This returns the physical size of all case files in that folder.

Retrieve the number of document translation requests

To return the number of document translation requests, use the countOfTranslationDocRequests field in the cases {statistics} object, as shown in the following example.

Sample query:

query MySampleQuery {
  cases {
    name
    statistics {
      countOfTranslationDocRequests
    }
  }
}

Sample results:

{
  “data”: {
    “cases”: [
      {
        “name”: “1_Acme6_PM2”,
        “statistics”: {
          “countOfTranslationDocRequests”: 0
        }
      }
    ]
  }
}

maxActiveHostedSize and dateOfMaxActiveHostedSize case statistics

There are two case statistics available that will return the maximum value of the aggregateActiveHostedSize and the date of that value within a specified date range.

Note: The aggregateActiveHostedSize statistic is the sum of sizeOfBaseDocumentsHostedDetails, sizeOfRenditionsHostedDetails, aggregateDatabases, sizeOfElasticSearchIndex, dtIndexSize, and sizeOfFolderData_Predict.

• maxActiveHostedSize: Returns the maximum value of aggregateActiveHostedSize within a specified date range. This value calculates from the first minute of the startDate (12:00:00am) to the last minute of the endDate (11:59:59pm) in Coordinated Universal Time (UTC).

• When only providing the endDate for the date range, the returned value is the highest value of the aggregateActiveHostedSize calculating from the beginning of the case to the last minute of the specified endDate.

• When there is no startDate or endDate provided, the returned value is the highest of the aggregateActiveHostedSize over the entire life of the case, from the beginning of the case through the current day.

• dateOfMaxActiveHostedSize: Returns the date of the maxActiveHostedSize within a specified date range.

• When only providing the endDate for the date range, the returned value is the date of the maxActiveHostedSize calculating from the beginning of the case to the last minute of the specified endDate.

• When there is no startDate or endDate provided, the returned value is the date of the maxActiveHostedSize over the entire life of the case, from the beginning of the case through the current day.

Sample query:

query MySampleQuery {
  cases {
    name
    statistics(startDate: “2020-04-01”, endDate: “2020-04-30”) {
      maxActiveHostedSize
      dateOfMaxActiveHostedSize
    }
  }
}

Sample results:

{
  “data”: {
    “cases”: [
      {
        “name”: “1_Acme6_PM2”,
        “statistics”: {
          “maxActiveHostedSize”: 770240752,
          “dateOfMaxActiveHostedSize”: “2020-04-13”
        }
      }
    ]
  }
}

Portal Management

Updates to portal management reporting statistics

This release includes the following updates to the cases {statistics} field:

• To return the total file size of files in the BatchPrint, export, ingest_temp, predict, suppressed, and upload folders in the application file system, you can now query the cases {statistics { sizeOfFolderData_BatchPrint sizeOfFolderData_Export sizeOfFolderData_Ingest_Temp sizeOfFolderData_Predict sizeOfFolderData_Suppressed sizeOfFolderData_Upload}} fields.
• The cases {statistics {sizeOfAllOtherFolderData}} field no longer includes files in these folders.

Productions

Cases[productions] field object for description, creator, and date

Cases{productions} has the following additional three fields. These fields enhance the reports you can generate for productions in your cases.

• description[string] returns the information in the Description column from the Productions page.
• creator[user] returns the information in the Creator column from the Productions page.
• date[date] returns the information in the Creation date or Locked date column from the Productions page. You can filter the date using the dateComparison operator.

The following example shows a query for a production using these fields.

Sample query:

query MySampleQuery {
  cases {
    productions (
      date:
      {
        value: “2018-01-01”,
        comparison:GreaterThan
      })
    {
       name
       description
       date
       creator {
         userName
      }
    }
  }
}

Sample results:

{
  “data”: {
    “cases”: [
      {
        “productions”: [
          {
            “name”: “!!23CloneTest”,
            “description”: “Clone of !23!”,
            “date”: “2020-04-23T16:39:58.677Z”,
            “creator”: {
              “userName”: “lfrost”
            }
          }
        ]
      }
    ]
  }
}

Reporting

Request the billable status of cases

You can request data about whether a case is billable using the cases {billingStatus} field. You can also filter to cases with a specific billing status using the cases(billingStatus: ENUM) { } argument.

Sample query:

query MySampleQuery {
  cases(billingStatus: Billable){
    name
    billingStatus
  }
}

Sample results:

{
  “data”: {
    “cases”: [
      {
        “name”: “1_Acme6_PM2”,
        “billingStatus”: “Billable”
      },
    ]
  }
}

Request the number of audio minutes transcribed for a case

To request the number of audio minutes transcribed for a case, use the case statistic countOfTranscribedAudioMinutes.p>

Sample query:

query MySampleQuery {
  cases {
    name
    statistics {
      countOfTranscribedAudioMinutes
    }
  }
}

Sample results:

{
  “data”: {
    “cases”: [
      {
        “name”: “1_Acme6_PM2”,
        “statistics”: {
          “countOfTranscribedAudioMinutes”: 0
        }
      }
    ]
  }
}

Request production information about documents

You can request data about the productions for a document, or a set of documents, using the cases {documents {documentProductions}} field.

Sample query:

query MySampleQuery {
  cases(name: “Clean_Enron”) {
    documents(mainIds: [100, 101, 102]) {
      productionDetails(scroll:{start: 0, limit: 20}) {
        production {
          name
          status
          docCount
          pageCount
          beginBates
          endBates
        }
        producedDocumentLabel
        minimumProducedPageLabel
        maximumProducedPageLabel
        printStatus
      }
    }
  }
}

Sample results:

{
  “data”: {
    “cases”: [
      {
        “documents”: [
          {
            “productionDetails”: [
              {
                “production”: {
                  “name”: “Biggie”,
                  “status”: “Unlocked”,
                  “docCount”: 1798685,
                  “pageCount”: 0,
                  “beginBates”: null,
                  “endBates”: null
                },
                “producedDocumentLabel”: null,
                “minimumProducedPageLabel”: null,
                “maximumProducedPageLabel”: null,
                “printStatus”: “NotPrinted”
              },
              {
                “production”: {
                  “name”: “Perf QC Rules Test (Worst Case) 1 million”,
                  “status”: “Unlocked”,
                  “docCount”: 999999,
                  “pageCount”: 0,
                  “beginBates”: null,
                  “endBates”: null
                },
                “producedDocumentLabel”: null,
                “minimumProducedPageLabel”: null,
                “maximumProducedPageLabel”: null,
                “printStatus”: “NotPrinted”
              }
            ]
          }
        ]
      }
    ]
  }
}

Query assignment data for report generation

API queries allow you to gather assignment data to generate reports that can show process workflows, phases, and user assignments.

The following lists the available fields for an assignment object query:

• id

• status: Object that extracts the following values:

• Unassigned

• Active

• Suspended

• Cleared

• Deleted

• Revoked

• workflow: Object to extract the following field data:

• description

• id

• name

• phases

• phases: Object to extract the following field data:

• documentsPerAssignment

• id

• locked

• name

• parentId

• parentPhaseName

• quickCode

• validationCriteriaName

• lot: Object to extract the following field data:

• id

• name

• name

• user

• assignedDate

• clearedDate

• createdDate

• clear

• total

Sample query:

query MySampleQuery {
  cases(id: 5) {
    reviewSetup {
      workflows(id: 1020) {
        phases(id: 79) {
          id
        }
        id
      }
      assignments(id: 1) {
        id
      }
    }
  }
}

Sample results:

{
  “data”: {
    “cases”: [
      {
        “reviewSetup”: {
          “workflows”: [
            {
              “phases”: [
                {
                  “id”: 79
                }
              ],
              “id”: 1020
            }
          ],
          “assignments”: [
            {
              “id”: 1
            }
          ]
        }
      }
    ]
  }
}

UserCaseReport query for retrieving caseUserCategory data

The query function contains a caseUserCategory field that retrieves the user categories and case groups of each user assigned to the identified case.

Sample query:

query UserCaseReport {
  cases(id: 7096) {
    id
    name
    groups {
      id
      name
      users {
        id
        caseUserCategory
      }
    }
  }
}

Sample query results:

{
  “data”: {
    “cases”: [
      {
        “id”: 7096,
        “name”: “1_Acme6_PM2”,
        “groups”: [
          {
            “id”: 1,
            “name”: “NDAdmin”,
            “users”: [
              {
                “id”: 7436,
                “caseUserCategory”: “GroupMember”
              },
              {
                “id”: 7437,
                “caseUserCategory”: “GroupMember”
              },
              {
                “id”: 7438,
                “caseUserCategory”: “GroupMember”
              },
              {
                “id”: 7439,
                “caseUserCategory”: “GroupMember”
              },
              {
                “id”: 7440,
                “caseUserCategory”: “GroupMember”
              },
              {
                “id”: 6311,
                “caseUserCategory”: “Administrator”
              },
              {
                “id”: 1,
                “caseUserCategory”: “Administrator”
              },
              {
                “id”: 101,
                “caseUserCategory”: “Administrator”
              },
              {
                “id”: 6,
                “caseUserCategory”: “GroupMember”
              },
              {
                “id”: 5289,
                “caseUserCategory”: “Administrator”
              }
            ]
          },
          {
            “id”: 2,
            “name”: “Review”,
            “users”: [
              {
                “id”: 6311,
                “caseUserCategory”: “Administrator”
              }
            ]
          }
        ]
      }
    ]
  }
}

Review Workflows

Request data about review workflows

You can request data about the names and number of distinct documents in review workflows using the cases {reviewWorkflow} field.

Sample query:

query MySampleQuery {
  cases(name: “Clean_Enron”) {
    reviewWorkflow {
      name
      count
    }
  }
}

Sample results:

{
  “data”: {
    “cases”: [
      {
        “reviewWorkflow”: [
          {
            “name”: “!HK”,
            “count”: 92803
          }
        ]
      }
    ]
  }
}

RPF Jobs

Request data about a specific RPF job

To obtain information about a specific RPF job, you can use the id argument in the jobs field of a rpf query.

Sample query:

query MySampleQuery {
  rpf {
    jobs(id: 628922) {
      case {
        name
        id
      }
      name
      status
      dateStarted
      dateFinished
      duration
    }
  }
}

Sample results:

{
  “data”: {
    “rpf”: {
      “jobs”: [
        {
          “case”: null,
          “name”: “Case Bulk Edit”,
          “status”: “Succeeded”,
          “dateStarted”: “2021-05-03T19:06:20.51Z”,
          “dateFinished”: “2021-05-03T19:06:41.283Z”,
          “duration”: “00:00:21”
        }
      ]
    }
  }
}

Search Results

Request data about search result sets

You can request data about search results sets using the cases {searchResults} field.

Sample query:

query MySampleQuery {
  cases(id: 5) {
    searchResults(id: 368918) {
      id
      count
      dateRun
      entityId
      fields {
        id
      }
      includeSourceAttachments
      threading
      renditions
      label
      searchRml
      user {
        userName
      }
    }
  }
}

Sample results:

{
  “data”: {
    “cases”: [
      {
        “searchResults”: [
          {
            “id”: 368918,
            “count”: 1855052,
            “dateRun”: “2021-07-07T16:58:50.163Z”,
            “entityId”: 1,
            “fields”: [
              {
                “id”: “162-6”
              },
              {
                “id”: “404-20”
              },
            ],
            “includeSourceAttachments”: false,
            “threading”: false,
            “renditions”: false,
            “label”: “--\”All Metadata and Coding\“ has a value ”,
            “searchRml”: “<search><criteria_grouping grouping=\” [1]\“/><search_criteria><criteria field_id=\”112\“ field_type_id=\”5\“ ringtail_type_id=\”54\“ operator=\”select_all\“ content_search_service_run_id=\”\“ criteria_id=\”1\“/></search_criteria></search>”,
            “user”: {
              “userName”: “lreichert”
            }
          }
        ]
      }
    ]
  }
}

Request data about fields in a search result set

When you query data about a search result set, you can request data about fields and the number of documents coded to the fields using the cases {searchResult {fields}} field.

Sample query:

query MySampleQuery {
  cases(id: 5) {
    searchResults(id: 368918) {
      fields {
        items {
          id
          name
          count
        }
        id
        count
        name
        entityId
      }
    }
  }
}

Sample results:

{
  “data”: {
    “cases”: [
      {
        “searchResults”: [
          {
            “fields”: [
              {
                “items”: [
                  {
                    “id”: 0,
                    “name”: “Coded”,
                    “count”: 1855052
                  },
                  {
                    “id”: 0,
                    “name”: “Not coded”,
                    “count”: 0
                  }
                ],
                “id”: “162-6”,
                “count”: 1855052,
                “name”: “Document Created By”,
                “entityId”: 1
              },
              {
                “items”: [
                  {
                    “id”: 0,
                    “name”: “Coded”,
                    “count”: 1817339
                  },
                  {
                    “id”: 0,
                    “name”: “Not coded”,
                    “count”: 37713
                  }
                ],
                “id”: “404-20”,
                “count”: 1817339,
                “name”: “Index Name”,
                “entityId”: 1
              },
            ]
          }
        ]
      }
    ]
  }
}

Request data about pages in documents

You can request data about the pages in a document, or a set of documents, using the cases {documents {pages}} field.

Sample query:

query MySampleQuery {
  cases(id: 5) {
    documents(mainIds: [100, 101, 102]) {
      pages {
        id
        fileName
        pageLabel
      }
      documentId
    }
  }
}

Sample results:

{
  “data”: {
    “cases”: [
      {
        “documents”: [
          {
            “pages”: [
              {
                “id”: 1870204,
                “fileName”: “000001522-00000059-00001.tif”,
                “pageLabel”: “000001522-00000059-00001”
              }
            ],
            “documentId”: “Enron_000000059”
          },
          {
            “pages”: [
              {
                “id”: 1870205,
                “fileName”: “000001522-00000061-00001.tif”,
                “pageLabel”: “000001522-00000061-00001”
              }
            ],
            “documentId”: “Enron_000000061”
          },
          {
            “pages”: [
              {
                “id”: 1870206,
                “fileName”: “000001522-00000068-00001.tif”,
                “pageLabel”: “000001522-00000068-00001”
              },
              {
                “id”: 1870207,
                “fileName”: “000001522-00000068-00002.tif”,
                “pageLabel”: “000001522-00000068-00002”
              }
            ],
            “documentId”: “Enron_000000068”
          }
        ]
      }
    ]
  }
}

Request data about annotations in documents

You can request data about the annotations in a document, or a set of documents, using the cases {documents {pages {annotations}}} field.

Sample query:

query MySampleQuery {
  cases {
    documents(mainIds: [101, 102, 103]) {
      pages {
        annotations {
          annotationType {
            id
            type
            color
            label
            name
          }
          color
          id
          pageNumber
          x1
          x2
          y1
          y2
        }
      }
    }
  }
}

Sample results:

{
  “data”: {
    “cases”: [
      {
        “documents”: [
          {
            “pages”: [
              {
                “annotations”: []
              }
            ]
          },
          {
            “pages”: [
              {
                “annotations”: [
                  {
                    “annotationType”: {
                      “id”: “35000-31”,
                      “type”: “REDACTION”,
                      “color”: “REDACTION”,
                      “label”: “Redaction_0001”,
                      “name”: “Redaction_0001”
                    },
                    “color”: “BLACK”,
                    “id”: 93908,
                    “pageNumber”: 1,
                    “x1”: 1041,
                    “x2”: 1183,
                    “y1”: 266,
                    “y2”: 425
                  }
                ]
              }
            ]
          }
        ]
      }
    ]
  }
}

You can request data about the annotations that are available in a case using the cases {annotationTypes} field.

Sample query:

query MySampleQuery {
  cases {
    annotationTypes {
      id
      type
      color
      label
      name
    }
  }
}

Sample results:

{
  “data”: {
    “cases”: [
      {
        “annotationTypes”: [
          {
            “id”: “40155-31”,
            “type”: “REDACTION”,
            “color”: “REDACTION”,
            “label”: “!Translation”,
            “name”: “-1!Translation=”
          },
        ]
      }
    ]
  }
}

Request data about ingested file size and other metrics

You can request data about ingested file size and other ingestion metrics using the cases {documentLoads} field.

Sample query:

query MySampleQuery {
  cases {
    documentLoads {
      unprocessedFiles
      processedFiles
      sourceFileCount
      sourceFileSize
      expandedItemCount
      expandedItemSize
      exceptionItemCount
      exceptionItemSize
      suppressedDateCount
      suppressedDateSize
      suppressedNISTCount
      suppressedNISTSize
      suppressedDupCount
      suppressedDupSize
      suppressedSTFCount
      suppressedSTFSize
    }
  }
}

Sample results:

{
  “data”: {
    “cases”: [
      {
        “documentLoads”: [
          {
            “unprocessedFiles”: 0,
            “processedFiles”: 0,
            “sourceFileCount”: 0,
            “sourceFileSize”: 0,
            “expandedItemCount”: 0,
            “expandedItemSize”: 0,
            “exceptionItemCount”: 0,
            “exceptionItemSize”: 0,
            “suppressedDateCount”: 0,
            “suppressedDateSize”: 0,
            “suppressedNISTCount”: 0,
            “suppressedNISTSize”: 0,
            “suppressedDupCount”: 0,
            “suppressedDupSize”: 0,
            “suppressedSTFCount”: 0,
            “suppressedSTFSize”: 0
          }
        ]
      }
    ]
  }
}

Request data about files associated with a document

You can request data about the files that are associated with a document using the cases {document {files}} object.

Sample query:

query MySampleQuery {
  cases {
    documents(mainIds: [101, 102, 103]) {
      files {
        id
        fileName
        fileExtension
        isContent
        contentFileRank
        isPage
        pageCount
        pageFileNumber
        sizeInBytes
      }
    }
  }
}

Sample results:

{
  “data”: {
    “cases”: [
      {
        “documents”: [
          {
            “files”: [
              {
                “id”: “C.1075053”,
                “fileName”: “Enron_000000061.mht”,
                “fileExtension”: “.mht”,
                “isContent”: true,
                “contentFileRank”: 1,
                “isPage”: false,
                “pageCount”: null,
                “pageFileNumber”: null,
                “sizeInBytes”: 2987
              }
            ]
          }
        ]
      }
    ]
  }
}

You can include the following arguments on the files object:

• id
• isContent
• isPage
• fileExtension

List document records from search results

You can request data about documents in a search result set using the documents field. The documents field returns a list of records of type document. By default, this returns 200 records per request, with a maximum limit of 1,000 records per request.

Sample query:

query MySampleQuery {
  cases(id: 5) {
    searchResults(id: 368918){
      id
      documents(scroll: {start: 0, limit: 30}) {
        documentId
        title
      }
    }
  }
}

Sample results:

{
  “data”: {
    “cases”: [
      {
        “searchResults”: [
          {
            “id”: 368918,
            “documents”: [
              {
                “documentId”: “Enron_000445893”,
                “title”: “DOC-000169950.mht”
              },
              {
                “documentId”: “Enron_000445894”,
                “title”: “DOC-000879937.xls”
              },
            ]
          }
        ]
      }
    ]
  }
}

UI Extensions

Request data about UI extensions

You can request data about UI extensions by querying the extensions object.

Sample query:

query MySampleQuery {
  extensions {
    name
    id
    description
    location
    url
    configuration
    createdDate
    createdByUser {
      userName
    }
  }
}

Sample results:

{
  “data”: {
    “extensions”: [
      {
        “name”: “WorkspacePaneToDelete”,
        “id”: 1,
        “description”: “Workspace Pane to deleted by Large Tests”,
        “location”: “Workspace”,
        “url”: “http://www.fticonsulting.com”,
        “configuration”: “”,
        “createdDate”: “2018-04-19T21:16:12.577Z”,
        “createdByUser”: {
          “userName”: “PortalAdmin”
        }
      }
    ]
  }
}

To return a list of organizations and see which have the extension enabled, you can query the extensions {organizations} field.

Sample query:

query MySampleQuery {
  extensions {
    name
    organizations {
      organization {
        name
        id
      }
      isEnabled
      configuration
    }
  }
}

Sample results:

{
  “data”: {
    “extensions”: [
      {
        “name”: “WorkspacePaneToDelete”,
        “organizations”: [
          {
            “organization”: {
              “name”: “organisation 1”,
              “id”: 1
            },
            “isEnabled”: false,
            “configuration”: null
          }
        ]
      }
    ]
  }
}

To return a list of cases and see which have the extension enabled, you can query the extensions {cases} field.

Sample query:

query MySampleQuery {
  extensions {
    name
    cases {
      case {
        name
        id
      }
      isEnabled
      configuration
    }
  }
}

Sample results:

{
  “data”: {
    “extensions”: [
      {
        “name”: “WorkspacePaneToDelete”,
        “cases”: [
          {
            “case”: {
              “name”: “Clean_Enron”,
              “id”: 5
            },
            “isEnabled”: false,
            “configuration”: null
          }
        ]
      }
    ]
  }
}

Request custom case statistics associated with UI extensions

You can request data about the custom case statistics that are associated with UI extensions using the cases {statistics {customStatistics}} object.

Sample query:

query MySampleQuery {
  cases {
    statistics {
      customStatistics {
        name
        id
        value
        extension {
          id
          name
        }
      }
    }
  }
}

Sample results:

{
  “data”: {
    “cases”: [
      {
        “statistics”: {
          “customStatistics”: [
            {
              “name”: “count_of_files___IngestAssistance”,
              “id”: 10000,
              “value”: 0,
              “extension”: null
            },
            {
              “name”: “size_of_files___IngestAssistance”,
              “id”: 10001,
              “value”: 0,
              “extension”: null
            },
            {
              “name”: “XLerator_Documents Processed”,
              “id”: 10002,
              “value”: 0,
              “extension”: {
                “id”: 8,
                “name”: “XLerator”
              }
            },
            {
              “name”: “XLerator_Documents Printed”,
              “id”: 10003,
              “value”: 0,
              “extension”: null
            }
          ]
        }
      }
    ]
  }
}

You can include the following arguments on the customStatistics object:

• id
• name
• extensionId

Request data for an enabled or disabled user for a portal-level UI extension

Use the affectedUser field to query results for a user who was enabled or disabled for a portal-level UI extension.

Sample query:

query MySampleQuery {
  extensions(id: 7) {
    id
    name
    url
    audit(startDate: “2018-05-01”, endDate: “2019-05-29”) {
      case {
        name
      }
      organization {
        name
      }
      affectedUser {
        fullName
      }
      isEnabled
      date
      user {
        fullName
      }
    }
  }
}

Sample results:

{
  “data”: {
    “extensions”: [
      {
        “id”: 7,
        “name”: “Portal home - user history”,
        “url”: “http://devring.dev.tech.local/UIStatic/extensions/test/index.html”,
        “audit”: [
          {
            “case”: null,
            “organization”: null,
            “affectedUser”: {
              “fullName”: “Administrator, Portal”
            },
            “isEnabled”: true,
            “date”: “2019-01-31T22:10:27.31Z”,
            “user”: {
              “fullName”: “Administrator, Portal”
            }
          }
        ]
      }
    ]
  }
}

Query extensions in the API

API queries can also retrieve extension data. This query will retrieve the following information:

• Id: Integer.
• Name: String.
• Location: Enumerator.
• Configuration: String.
• Description: String.
• URL: String.

Sample query:

query MySampleQuery {
  extensions {
    id
    name
    location
    configuration
    url
    description
    createdDate
    createdByUser {
      id
      fullName
    }
  }
}

Sample results:

{
  “data”: {
    “extensions”: [
      {
        “id”: 1,
        “name”: “WorkspacePaneToDelete”,
        “location”: “Workspace”,
        “configuration”: “”,
        “url”: “http://www.fticonsulting.com”,
        “description”: “Workspace Pane to deleted by Large Tests”,
        “createdDate”: “2018-04-19T21:16:12.577Z”,
        “createdByUser”: {
          “id”: 165,
          “fullName”: “Administrator, Portal”
        }
      }
    ]
  }
}

Updates to Pages

Updates to the Cases{documents{pages}} field object

This release includes the following updates to the cases {documents {pages}} object:

• The pageFileNumber field replaces the previous cases {documents {pages {pageNum}}} field name.
• The pageCount field replaces the previous cases {documents {pages {numPages}}} field name.

Sample Mutations

General Information

Create an import job

You can create an import job in a case using the importJobCreate mutation. This mutation returns the rdxJobID field value used in the next mutation to add documents to the import job. This mutation also allows you to configure some job level settings.

Sample mutation:

mutation MySampleMutation {
  importJobCreate
  (
    caseId: 5,
    input: 
    {
      description: “test”,
      name: “Clean Enron”,
      documentIdType: Existing
    }
  )
  {
    rdxJobId
  }
}

Sample results:

{
  “data”: {
    “importJobCreate”: {
      “rdxJobId”: 319
    }
  }
}

Configurable options:

• name: String is the name of the import job. If you do not provide a value for this option, the job name is “Import from API.
• description: String is the description of the import job. If you do not provide a value for this option, the job description is ”Import from API.“
• level: String determines the root level to put documents in. If you do not provide a value for this option, the level is ”API/{ImportID}/0001.“ Level values assigned to documents in the importJobAddDocuments mutation override this setting.
• docsPerLevel: Int determines the maximum number of documents per level. If you do not provide a value for this option, the value is 1000.
• updateGroupCoding: Boolean updates the group coding fields (All Custodians, for example) for new documents in this import and any existing or future family duplicate documents. If you do not provide a value for this option, the value is ”false.“

Add documents to an import job

Use the returned values, from the importJobCreate mutation, in the importJobAddDocuments mutation to add documents to an import job. Each importJobAddDocuments mutation allows you to add up to 5000 documents. To add additional documents to the job, run multiple mutations with different documents.

Note: When defining the path value for pages and content files, the path is relative to the ”import“ folder in the Image file repository defined for the case.

For example, if the path is defined as follows:

path:”Imports\\Media0001\\Images\\0001\\DOC-00000001.tif“

then the file should be located at:

{Image file repository}\import\{case name}\Imports\Media0001\Images\0001\DOC-00000001.tif.

Sample mutation:

mutation MySampleMutation{
  importJobAddDocuments(caseId: 5,
  input: {
    rdxJobId: 4128,
    documents: {
      documentId: ”ACTEST_00000001“,
      issues: {
        values: [”Top Issue/subissue 1“,”Top Issue-subissue 2“]
      },
      fields: {
        name: ”All Custodians“,
        action: Append,
        values: ”Custodian from API“
      }
    }
  }){
    documentCount
  }
}

Sample results:

{

  ”data“: 

{

    ”importJobAddDocuments“: 

{

      ”documentCount“: 

1

}

}

}

Configurable options:

• documentId: String! imports the Document ID of the document.

• hash: String imports the individual MD5 hash value of the document and adds this value to the [RT] MD5 Hash field in the case.

• familyhash: String imports the family MD5 hash value of the document and adds this value to the [RT] Family MD5 Hash field in the case.

• level: String, when set, overrides any level data set in the job options and will not update for existing documents.

• parentId: String is the parent document ID for the document that establishes a source/attachment relationship. The source/attachment relationship is either updated or deleted depending on the value set for sourceattachmentaction.

• sourceattachmentaction: SAAction determines which of the following actions to take for the parentId field:

• Delete removes coding from the document for the field.

• InsertUpdate inserts or updates the value(s) of the field.

• pageaction: Action determines which of the following actions to take on the pages:

• Update inserts or updates the value(s) of the field.

• Delete removes coding from the document for the field.

• Ignore ignores the value.

• mainfields: [DocumentFieldParams] imports the following data into core document fields in the case.

• name: DocumentField! is the name of the document field. The names correspond to the core document fields in the case: DocumentDate, DocumentDescription, DocumentTitle, DocumentType, EstimatedDate.

• value: String determines which of the following values to populate in the document field.

• DocumentDate is the Document Date of the document. Format is YYYY-MM-DD.

• DocumentDescription is the Document Description of the document.

• DocumentTitle is the Document Title of the document.

• DocumentType is the Document Type of the document.

• EstimatedDate is the Estimated Date of the document and is a Boolean value.

• action: CoreAction! determines which of the following actions to take on the incoming field data:

• Update inserts or updates the value(s) of the field.

• Delete removes coding from the document for the field.

• Ignore ignores the value.

• fields: [FieldParams] imports the following data into fields in the case:

• name: String! is the name of the field. The mutation will use the field if it already exists. Otherwise, if the field does not exist, the mutation creates the name with the field type indicated.

• onetomany: Boolean defines whether the field is one to many.

• type: FieldType! is the field type. The possible values are as follows:

• Boolean allows you to set the value as Yes or No.

• DateTime allows you to set the value in YYYY-MM-DD format.

• Memo

• Number

• PickList

• Text

• action: Action! determines which of the following actions to take on the incoming data:

• Append appends the value(s) to the field (only for one-to-many field types).

• Delete removes coding from the document for the field.

• InsertUpdate inserts or updates the value(s) of the field.

• values: [String]! imports the value(s) for the field.

• correspondence: [CorrespondenceType] imports the following people and organization values for the document:

• type: String! determines the correspondence type. Possible values are To, From, CC, or BCC.

• people: [String] contains a list of people values.

• orgs: [String] contains a list of organization values.

• action: Action! determines which of the following actions to take on the incoming field data:

• Append appends the value(s) to the field (only for one-to-many field types).

• Delete removes coding from the document for the field.

• InsertUpdate inserts or updates the value(s) of the field.

• pages: [PagesParams]imports the following values for the pages associated with the document:

• pagenumber: Int! is the page number.

• pagelabel: String is the page label of the page.

• path: String! is the location of the physical file to upload.

• contentfiles: [ContentFileParams] imports the list of content files for the document.

• path: String! imports the location of the physical file to upload.

Submit an import job

After adding documents to a job using the importJobAddDocuments mutation, you can run the import job using the importJobSubmit mutation.

Sample mutation:

mutation MySampleMutation {
  importJobSubmit (
    caseId: 5,
    input: {
      rdxJobId: 10
    }
  )
  {
    rpfJobId
  }
}

Sample results:

{
  ”data“: {
    ”importJobSubmit“: {
      ”rpfJobId“: 708581
    }
  }
}

User account management

userUpdate mutation for administration tasks

The userUpdate mutation allows administrators to perform updates to multiple user accounts simultaneously. When building this mutation, you must include the userId field to identify the user accounts.

Optional fields:

• firstName
• lastName
• email
• companyId
• identityProviderId
• portalCategory
• disabled
• requirePasswordChange: Previously named forceReset
• licenses
• password
• addToActiveDirectory
• forceResetChallengeQuestions

Important: When passing a field value that is blank, the mutation will remove the field. For example, the mutation will remove the disabled field if you enter disabled: ”“. When entering new values for either the firstName or lastName, the mutation updates the entire name.

Sample mutation:

mutation MySampleMutation {
  userUpdate(input: [
    {userId: 200, firstName: ”Fred“, lastName: ”Doo“},
    {userId: 1, firstName: ”Velma“},
    {userId: 1, lastName: ”Doo“}
  ]) {
    users {
      id
      fullName
    }
  }
}

Sample results:

{
  ”data“: {
    ”userUpdate“: {
      ”users“: [
        {
          ”id“: 200,
          ”fullName“: ”Doo, Fred“
        },
        {
          ”id“: 1,
          ”fullName“: ”Doo, Velma“
        },
        {
          ”id“: 1,
          ”fullName“: ”Doo, Velma“
        }
      ]
    }
  }
}

userAdd mutation

The mutation userAdd allows the addition of new user accounts using the API. The following lists the accepted input data for this mutation.

• firstName: Required data.
• lastName: Required data.
• username: Required data.
• password: Required data.
• email
• licenses: Default is Yes.
• requirePasswordChange: Default is Yes.
• portalCategory: Required and follows the same rules as in the user interface (UI) of what the user passing in the mutation can assign.
• organizationID: Follows the same rules as in the UI of what the user passing in the mutation can assign.
• companyID
• addtoActiveDirectory: Required and default is Yes.

The following is an example of how to use this mutation.

Sample mutation:

mutation MySampleMutation {
  userAdd
  (
    input: 
    {
      licenses: 1,
      addToActiveDirectory: true,
      firstName: ”New1“,
      lastName: ”User1“,
      email: ”newuser@user.com“,
      password: ”Qwerty123456“,
      portalCategory: PortalAdministrator,
      userName: ” newuser091283“
    }
  ) 
  {
    users {
      id
      organizations {
        name
        id
        accountNumber
      }
      identityProvider
      userName
      fullName
      companyName
    }
  }
}

Sample results:

{
  ”data“: {
    ”userAdd“: {
      ”users“: [
        {
          ”id“: 6382,
          ”organizations“: [],
          ”identityProvider“: ”NuixDiscover“,
          ”userName“: ”newuser091283“,
          ”fullName“: ”User1, New1“,
          ”companyName“: null
        }
      ]
    }
  }
}

userDelete mutation

The mutation userDelete allows the deletion of user accounts using the API so that you can integrate your user management application with Nuix Discover. The following lists the accepted input data for this mutation.

• If all users exist, executing the userDelete mutation with single or multiple userid values will delete all specified users.
• If some users do not exist, executing the userDelete mutation with single or multiple userid values will delete the specified valid users. In return, the user id values as null.
• If no users exist, executing the userDelete mutation with single or multiple userid values will return, the user id values as null.

Fields:

• userID: An integer that identifies the user in the portal.

The following is an example of how to use this mutation.

Sample mutation:

mutation MySampleMutation {
  userDelete(input: {userId: [231]}) {
    users {
      id
    }
  }
}

Sample results:

{
  ”data“: {
    ”userDelete“: {
      ”users“: [
        {
          ”id“: 231
        }
      ]
    }
  }
}

Annotations

Add an annotation to a page in a document

You can add an annotation to a page in a document using the annotationAdd mutation.

Sample mutation:

mutation MySampleMutation {
  annotationAdd
  (
    caseId: 5,
    input: {
      annotationTypeId: ”709-30“,
      mainId: 1001,
      pageId: 1072016,
      color: RED,
      pageNumber: 1,
      x1: 0,
      x2: 1,
      y1: 0,
      y2: 1
    }
  ) 
  {
    totalCount
  }
}

Sample results:

{
  ”data“: {
    ”annotationAdd“: {
      ”totalCount“: 1
    }
  }
}

Where:

• The ringtailTypeId is 30 for highlights or 31 for redactions.
• The annotationListId is the ID of the annotation type in the case obtained by querying {cases{annotationTypes{id name}}} and using the portion of the id field result before the hyphen. For example, if {cases{annotationTypes{id name}}} returns { ”id “: ”10463-30 “, ”name “: ”Attorney-Client “} for the highlight you want to add, specify 10463 as the annotationListId in the mutation.

Note: This value may not be valid for annotation types created in earlier versions of the application.

• The x1, x2, y1, and y2 fields indicate the position of the annotation in pixels, as follows:

• The top left corner of the page is at the coordinates (0, 0).

• Use the coordinates (x1, y1) to indicate the top left corner of the annotation.

• Use the coordinates (x2, y2) to indicate the bottom right corner of the annotation.

• Provide all coordinates in positive integers.

Delete an annotation from a page in a document

You can delete an annotation from a page in a document using the annotationDelete mutation.

Sample mutation:

mutation MySampleMutation {
  annotationDelete(caseId: 5, input: {
    annotationId: 40155,
    mainId: 1001,
    pageId: 1072016
  }) {
    successCount
    errorCount
    erroredItems {
      annotationId
      error
    }
    totalCount
  }
}

Sample results:

{
  ”data“: {
    ”annotationDelete“: {
      ”successCount“: 1,
      ”errorCount“: 0,
      ”erroredItems“: [],
      ”totalCount“: 1
    }
  }
}

Updates to the annotationAdd mutation

The annotationAdd mutation adds an annotation to a page in a document.

Sample mutation:

mutation MySampleMutation {
  annotationAdd(caseId: 5, input: {
    mainId: 1001,
    pageId: 1072016,
    pageNumber: 1,
    annotationTypeId: ”709-30“,
    x1: 10,
    x2: 11,
    y1: 10,
    y2: 11,
    color: RED,
    referenceId: ”abc“
  }) {
    totalCount
    successCount
    successItems {
      referenceId
      annotationId
    }
    errorCount
    erroredItems {
      referenceId
      error
    }
  }
}

Sample results:

{
  ”data“: {
    ”annotationAdd“: {
      ”totalCount“: 1,
      ”successCount“: 1,
      ”successItems“: [
        {
          ”referenceId“: ”abc“,
          ”annotationId“: 102383
        }
      ],
      ”errorCount“: 0,
      ”erroredItems“: []
    }
  }
}

The changes are:

• caseId is now a separate parameter from the other input parameters. This means that you can annotate documents in only one case per request.
• The input parameter replaces the previous parameter named annotationInputTypes.
• The annotationTypeId parameter replaces and combines the previous parameters named annotationListId and ringtailTypeId parameters.
• The referenceId parameter allows you to provide a custom string to differentiate multiple inputs that you submit with a single request. You can use the referenceId to determine which specific inputs succeeded or failed.
• The results payload field is no longer available. Payload fields for successCount, successItems, errorCount, and erroredItems are now available.

Coding

Code documents with a value for a pick list

You can code documents with a value for a pick list using the fieldCode mutation.

Sample mutation:

mutation MySampleMutation {
  fieldCode (input: {
    action: Insert,
    caseId: 5,
    fieldId: ”10016-19“,
    mainIds: 1001,
    value: ”519“
  }) {
    caseId
    codedValue
    fieldId
    insertedCount
    updatedCount
    deletedCount
    notChangedCount
    totalCodedCount
    changes {
      mainId
      result
      value
    }
  }
}

Sample results:

{
  ”data“: {
    ”fieldCode“: [
      {
        ”caseId“: 5,
        ”codedValue“: ”519“,
        ”fieldId“: ”10016-19“,
        ”insertedCount“: 0,
        ”updatedCount“: 0,
        ”deletedCount“: 0,
        ”notChangedCount“: 0,
        ”totalCodedCount“: 0,
        ”changes“: []
      }
    ]
  }
}

Apply a coding action using the fieldCode mutation

The fieldCode mutation allows you to apply the coding action (add, update, delete or save a field value) to a specified document in a case. You can use the mutation to code a text field, date field, number field, memo field, Boolean field, or pick list.

The mutation returns an error if you do not have access to the case and document and write permission to the field, and if you specify an invalid caseId, mainId, or fieldId.

The following example updates the field 10406-8 with a value of 18772.

Sample mutation:

mutation MySampleMutation {
  fieldCode
  (
    input: {
      caseId: 5,
      action: Save,
      mainIds: [1001, 1002, 1003],
      fieldId: ”10016-19“,
      value: ”519“
    }
  ) 
  {
    fieldId
    updatedCount
    totalCodedCount
    deletedCount
    notChangedCount
    changes {
      mainId
      result
      value
    }
  }
}

Sample results:

{
  ”data“: {
    ”fieldCode“: [
      {
        ”fieldId“: ”10016-19“,
        ”updatedCount“: 3,
        ”totalCodedCount“: 3,
        ”deletedCount“: 0,
        ”notChangedCount“: 0,
        ”changes“: [
          {
            ”mainId“: 1001,
            ”result“: ”Update“,
            ”value“: ”519“
          },
          {
            ”mainId“: 1002,
            ”result“: ”Update“,
            ”value“: ”519“
          },
          {
            ”mainId“: 1003,
            ”result“: ”Update“,
            ”value“: ”519“
          }
        ]
      }
    ]
  }
}

Update or delete coding values using the fieldCodeUpdateSpecific and fieldCodeDeleteSpecific mutations

Use the fieldCodeUpdateSpecific and fieldCodeDeleteSpecific mutations to update or delete coding values for specific fields.

For fieldCodeUpdateSpecific, you must specify a coded value to replace and the new value to replace it with, as shown in the following example. The mutation will replace only the specified value for a one-to-many field. Other values coded to the document are unchanged.

Like the fieldCode mutation, you must have access to the case and document, write permission to the field, and valid values for caseId, mainId, or fieldId.

Sample mutation:

mutation MySampleMutation {
  fieldCodeUpdateSpecific
  (
    input: {
      caseId: 5,
      mainIds: 1001,
      fieldId: ”10016-19“,
      newValue: ”530“,
      existingValue: ”519“
    }
  ) 
  {
    fieldId
    insertedCount
    updatedCount
    totalCodedCount
    deletedCount
    notChangedCount
    changes {
      mainId
      result
      value
    }
  }
}

Sample results:

{
  ”data“: {
    ”fieldCodeUpdateSpecific“: [
      {
        ”fieldId“: ”10016-19“,
        ”insertedCount“: 0,
        ”updatedCount“: 0,
        ”totalCodedCount“: 0,
        ”deletedCount“: 0,
        ”notChangedCount“: 0,
        ”changes“: []
      }
    ]
  }
}

For fieldCodeDeleteSpecific, you must specify the value to delete. The following example deletes the value updated in the fieldCodeUpdateSpecific example.

Sample mutation:

mutation MySampleMutation {
  fieldCodeDeleteSpecific
  (
    input: {
      caseId: 5,
      mainIds: 1001,
      fieldId: ”10016-19“,
      existingValue: ”519“
    }
  ) 
  {
    fieldId
    insertedCount
    updatedCount
    totalCodedCount
    deletedCount
    notChangedCount
    changes {
      mainId
      result
      value
    }
  }
}

Sample results:

{
  ”data“: {
    ”fieldCodeDeleteSpecific“: [
      {
        ”fieldId“: ”10016-19“,
        ”insertedCount“: 0,
        ”updatedCount“: 0,
        ”totalCodedCount“: 1,
        ”deletedCount“: 1,
        ”notChangedCount“: 0,
        ”changes“: [
          {
            ”mainId“: 1001,
            ”result“: ”Delete“,
            ”value“: ”519“
          }
        ]
      }
    ]
  }
}

Search coding history values using the PreviousValueEverWas operator

The operator PreviousValueEverWas is now available in the API for searching on values in coding history.

Sample mutation:

mutation MySampleMutation {
  searchRun 
  (
    caseId: 2,
    input: {
      include: MatchingItems,
      renditions: false,
      singleQuery: {
        field: ”Document ID“,
        operator: PreviousValueEverWas,
      value: ”A“
    }
  }
  ) 
  {
    id
    label
    count
    dateRun
    entityId
    items {
      id
      itemId
    }
  }
}

Sample results:

{
  ”data“: {
    ”searchRun“: {
      ”id“: 742,
      ”label“: ”--\“Document ID\” previous value ever was \“A\”“,
      ”count“: 0,
      ”dateRun“: ”2020-06-19T14:18:53.027Z“,
      ”entityId“: 1,
      ”items“: []
    }
  }
}

User assignments

Assign users to case groups using the userGroupAssign mutation

The userGroupAssign mutation allows you to easily assign users to case groups for easy management of case access. This mutation allows you to perform multiple assignments simultaneously by pairing a single userId to a groupId, or multiple userIds to a groupId. Only the userId field allows this many-to-one assignment format. All other fields can only assign in a one-to-one format.

When assigning a user to a group and the user has an existing assignment to that group, the notChangedCount will increase by the appropriate number.

Required fields:

• userId
• caseId
• groupId

Sample mutation:

mutation MySampleMutation {
  userGroupAssign
  (
    input: [
      {
        userId: [7,9,10,11],
        groupId: 13,
        caseId: 8
      },
      {
        userId: 8,
        groupId: 13,
        caseId: 4
      }
  ]
  ) 
  {
    totalCount
    successCount
    errorCount
    notChangedCount
  }
}

Sample results:

{
  ”data“: {
    ”userGroupAssign“: {
      ”totalCount“: 5,
      ”successCount“: 5,
      ”errorCount“: 0,
      ”notChangedCount“: 0
    }
  }
}

Unassign users from case groups using the userGroupUnassign mutation

The userGroupUnassign mutation allows the ability to unassign a user from a case group for managing case access. Portal Administrators assigned to a case can unassign Portal Users and other Portal Administrators from the groups in that case.

Required fields:

• userId: Integer, identifies the user in the portal.
• caseId: Integer, identifies the case in the portal.
• groupId: Integer, identifies the user group in the case.

Sample mutation:

mutation MySampleMutation {
  userGroupUnassign
  (
    input: [
    {
      userId: [7,9,10,11],
      groupId: 13,
      caseId: 8
    },
    {
      userId: 8,
      groupId: 13,
      caseId: 4
    }
  ]
  )
  {
    totalCount
    successCount
    errorCount
    notChangedCount
  }
}

Sample results:

{
  ”data“: {
    ”userGroupUnassign“: {
      ”totalCount“: 5,
      ”successCount“: 5,
      ”errorCount“: 0,
      ”notChangedCount“: 0
    }
  }
}

Remove assigned users from cases using the userCaseUnassign mutation

The userCaseUnassign mutation allows you to remove assigned users from cases for easy management of case access. This mutation allows you to remove multiple assignments simultaneously by pairing a single userId to a caseId, or multiple ids to a caseId. Only the userId field allows this many-to-one removal format. All other fields can only remove in a one-to-one format.

When assigning a user to an organization, if the user has an existing assignment to that organization, the notChangedCount field will increase by the appropriate number.

Required fields:

• userId
• caseId

Sample mutation:

mutation MySampleMutation {
  userCaseUnassign
  (
    input: [
      {
        userId: [7,9,10,15],
        caseId: 5
      },
      {
        userId: 11,
        caseId: 5
      },
      {
        userId: 8,
        caseId: 5
      }
      ]
  ) 
  {
    totalCount
    successCount
    errorCount
    notChangedCount
  }
}

Sample results:

{
  ”data“: {
    ”userCaseUnassign“: {
      ”totalCount“: 6,
      ”successCount“: 4,
      ”errorCount“: 0,
      ”notChangedCount“: 2
    }
  }
}

Assign users to organizations using the userOrganizationAssign mutation

The userOrganizationAssign mutation allows you to assign users to organizations to help manage user assignments. This mutation allows you to perform multiple assignments simultaneously by pairing a single userId to an organizationId, or multiple ids to an organizationId. Only the userId field allows this many-to-one assignment format. All other fields can only assign in a one-to-one format.

When assigning a user to an organization, if the user has an existing assignment to that organization, the notChangedCount field will increase by the appropriate number.

Required fields:

• userId
• organizationId

Sample mutation:

mutation MySampleMutation {
  userOrganizationAssign
  (
    input: [
      {
        userId: [7,9,10,15],
        organizationId: 4
      },
      {
        userId: 7,
        organizationId: 4
      },
      {
        userId: 8,
        organizationId: 4
      }
      ]
  ) 
  {
    totalCount
    successCount
    errorCount
    notChangedCount
  }
}

Sample results:

{
  ”data“: {
    ”userOrganizationAssign“: {
      ”totalCount“: 6,
      ”successCount“: 0,
      ”errorCount“: 0,
      ”notChangedCount“: 6
    }
  }
}

Assign users to cases using the userCaseAssign mutation

The userCaseAssign mutation allows you to easily assign users to cases for easy management of case access. This mutation allows you to perform multiple assignments simultaneously by pairing a single userId to a caseId, or multiple ids to a caseId. Only the userId field allows this many-to-one assignment format. All other fields can only assign in a one-to-one format.

New assignments automatically set the Access Restrictions to None as the default. Currently, the mutation does not have the ability to change this setting to another option. You must modify these settings manually through the UI.

When assigning a user to a case, if the user has an existing assignment to that case, leaving the caseGroupId field blank will not change the existing caseGroupId data for that user. When re-adding a previously assigned user to a case without specifying a group, the mutation will place that user back into the same group to which they previously belonged prior to removal.

When assigning a user to an organization, if the user has an existing assignment to that organization, the notChangedCount field will increase by the appropriate number.

Note: Portal administrators will not have the ability to assign a user to a case that is outside their own organization.

Required fields:

• userId
• caseId
• caseUserCategory

Optional fields:

• caseGroupId

Sample mutation:

mutation MySampleMutation {
  userCaseAssign
  (
    input: [
      {
        userId: [7,9,10,15],
        caseId: 5,
        caseUserCategory: Administrator,
        caseGroupId: 10
      },
      {
        userId: [8],
        caseId: 5,
        caseUserCategory: GroupMember,
        caseGroupId: 10
      }
      ]
  )
  {
    totalCount
    successCount
    errorCount
    notChangedCount
  }
}

Sample results:

{
  ”data“: {
    ”userCaseAssign“: {
      ”totalCount“: 5,
      ”successCount“: 1,
      ”errorCount“: 0,
      ”notChangedCount“: 4
    }
  }
}

Organization settings

Update organization settings using the organizationUpdate mutation

The organizationUpdate mutation gives system and portal administrators the ability to update organization settings to help manage the organizations within the application.

Required fields:

• organizationId: Integer, identifies the organization in the portal.

Optional fields:

• name: String, organization name in the portal
• accountNumber: Is a string containing the account number of the organization.
• caseId: Is an integer identifying the default template case for the organization in the portal.

Sample mutation:

mutation MySampleMutation {
  organizationUpdate
  (
    input: {
      organizationId: 6,
      caseId: 5,
      name: ”ABC Corp“,
      accountNumber: ”87597117“
    }
  ) 
  {
    totalCount
    successCount
    notChangedCount
    errorCount
  }
}

Sample results:

{
  ”data“: {
    ”organizationUpdate“: {
      ”totalCount“: 1,
      ”successCount“: 1,
      ”notChangedCount“: 0,
      ”errorCount“: 0
    }
  }
}

Custom Case Statistics

Edit a value for custom case statistics

You can edit the value for a custom case statistic using the caseStatisticsAdd mutation. Custom case statistics are an optional component of the settings for a UI extension.

Sample mutation:

mutation MySampleMutation {
  caseStatisticsAdd(input: {
    caseId: 5,
    id: 10003,
    value: 207,
    date: ”2018/08/07“
  }) {
    caseId
    id
    value
  }
}

Sample results:

{
  ”data“: {
    ”caseStatisticsAdd“: [
      {
        ”caseId“: 5,
        ”id“: 10003,
        ”value“: 414
      }
    ]
  }
}

Note the following:

• The id is the ID of the custom case statistic to update (refer to the Request data about the custom case statistics query for an example of requesting this data). The IDs for custom case statistics start at 10001.
• The value is the amount that you want to add to the current value of the custom case statistic. For example, if the current value is 10 and you specify a value of 7 in the mutation, the application updates the value to 17.
• The date field is optional. If you do not specify a value, the value defaults to the current date and time, in UTC.

Data Models

Add entity items

You can add new entity items for data models using the entityItemAdd mutation. The mutation creates a new entity item of the specified type entityTypeID.

Sample mutation:

mutation MySampleMutation {
  entityItemAdd (
    caseId: 5,
    input: {
      entityTypeId: 5
    }
  ) 
  {
    id
    itemId
    fields (
      fields: {
        id: ”10001“,
        name: ”FaceBook“
      }
    ) 
    {
      id
    }
  }
}

Sample results:

{
  ”data“: {
    ”entityItemAdd“: [
      {
        ”id“: 1951868,
        ”itemId“: ”0000008901“,
        ”fields“: null
      }
    ]
  }
}

Case cloning

Clone cases using caseClone mutation

The caseClone mutation allows you to quickly create cases without having to use the Nuix Discover UI. The following describes the mutation acceptance criteria.

Required fields:

• caseName
• organizationId: Used to identify an organization’s default template used for cloning.

Optional fields:

• sourceCaseId: Data based on a user’s organization. If the sourceCaseId is missing and there is a selected default template, the mutation uses the organization’s default template case. If the sourceCaseId is missing and there is no default template selected, the application returns the following message: A sourceCaseId<strong> must be included in this mutation when an organization does not have a default template case.
• Description
• scheduleMetricsJob = true (default): If true, schedule is set to Monthly on day 31 at 11:00 PM.

The following lists the non-configurable fields that inherit the organization’s default or have a hard-coded default:

• active = true (default)
• clearData = true (default)
• databaseServerId
• imageRepositoryId
• indexRepositoryId
• fileTransferRepositoryId
• analysisServerId
• archiveRepositoryId
• externalRepositoryId

The following lists examples of some of the available result fields for use in the caseClone mutation:

• processingStatus: Object that extracts the following case processing status:

• Failure

• Pending

• Queued

• Succeeded

• SucceededWithWarnings

• processingType: Object that extracts the following case processing type:

• Clone

• Connect

• Create

• Decommission

• DeleteDecommissionCase

• Edit

• Recommission

Note: This mutation does not support the process of setting the case metrics schedule to (daily (time)), (Weekly (week day, time)), (monthly(day, time)).

Sample mutation with defaults:

mutation MySampleMutation {
  caseClone (
    input: {
    organizationId: 6,
    sourceCaseId: 5,
    caseName: ”My New Clone“
  }) 
  {
    case {
      id
    }
  }
}

Sample results:

{
  ”data“: {
    ”caseClone“: {
      ”case“: {
        ”id“: 9183
      }
    }
  }
}

Sample mutation with options:

mutation MySampleMutation {
  caseClone (input: {
    organizationId: 6,
    sourceCaseId: 5,
    caseName: ”My new clone 2“
    description: ”This is my cloned case“,
    scheduleMetricsJob: true
  }) {
    case {
      id
    }
  }
}

Sample results:

{
  ”data“: {
    ”caseClone“: {
      ”case“: {
        ”id“: 9184
      }
    }
  }
}

Cross organization cloning using caseClone mutation

The mutation caseClone now allows the cloning of organizations without using the UI Extensions. The following is the acceptance criteria when using this process.

Required Fields:

• caseName: Required data.

• organizationId: Required data.

• souceCaseId: Optional data with defaults based on user’s organization.

• When not included, the mutation will use the organization’s default case template.

• When not included and there is no default case template, the mutation uses the portal default case template.

• When not included and there is no default case template or a portal case template, the application returns the following message: A sourceCaseId must be included in this mutation when the portal and organization do not have a default template case.

• description: Optional data.

• scheduleMetricsJob = true (default): Optional data. If true, schedule is set to Monthly on day 31 at 11:00 PM.

• The mutation does not support setting the case metrics schedule as (daily (time)), (Weekly (week day, time)), (monthly(day, time)).

The following are non-configurable fields and inherit the organization defaults or have a hard-coded default:

• active = true (default)
• clearData = true (default)
• databaseServerId
• imageRepositoryId
• indexRepositoryId
• fileTransferRepositoryId
• analysisServerId
• archiveRepositoryId
• externalRepositoryId

The following is an example of how to use these defaults and options.

Sample mutation with defaults:

mutation MySampleMutation {
  caseClone(input: {
    sourceCaseId: 5,
    caseName: ”My new cloned case 3“
  }) {
    case {
      id
    }
  }
}

Sample results:

{
  ”data“: {
    ”caseClone“: {
      ”case“: {
        ”id“: 9185
      }
    }
  }
}

Sample mutation with options:

mutation MySampleMutation {
  caseClone(input: {
    organizationId: 6,
    sourceCaseId: 5,
    caseName: ”My new cloned case 4“,
    description: ”This case is described“,
    scheduleMetricsJob: true
  }) {
    case {
      id
    }
  }
}

Sample results:

{
  ”data“: {
    ”caseClone“: {
      ”case“: {
        ”id“: 9186
      }
    }
  }
}

Import API

Run indexing and enrichment using importJobCreate mutation

The importJobCreate mutation now contains a parameter for running an indexing and enrichment job after an import job completes.

• Name: runIndexing
• Type: Boolean
• Required: No
• Default: false

The following is an example of how to use this parameter.

Sample mutation:

mutation MySampleMutation {
  importJobCreate (
    caseId: 5,
    input: {
      name:”My Import Job“,
      description:”Import job description“,
      level:”Imports/Custodian A/0001“,
      docsPerLevel: 1000,
      updateGroupCoding:true,
      runIndexing:true      
    }
  )
  {
    rdxJobId
  }
}

Sample results:

{
  ”data“: {
    ”importJobCreate“: {
      ”rdxJobId“: 52093
    }
  }
}

Note: If this parameter is set to true, an indexing and enrichment process will run after the import job.

Run deduplication in import job

The importJobCreate mutation now allows the option to suppress documents from the import job as duplicates. When the runDeduplication parameter is set to true, the job will use the deduplication settings associated with Ingestions processing as follows:

• Use the default setting for Case or Custodian. If there is no default setting, use Case.
• Use the default setting for Only use the top parent documents to identify duplicates. If there is no default setting, use False.
• Do not retain suppressed files regardless of the setting.

The following are some additional considerations that will take place during processing:

• The Imports feature codes all imported documents with a Yes in the Exclude from Ingestions Deduplication field. Coding of this field will not take place if selecting deduplicate and the setting is Case or Custodian.
• The files within suppressed documents will not transfer.
• If suppressing a document that contains an existing document ID in main_suppressed, the application returns the following message: Document <doc ID> was identified as a duplicate to be suppressed, but it was not suppressed because a document with the same Document ID has already been suppressed in this case.

In the importJobCreate mutation, add one or more of the following parameters under input:

• Name: runDeduplication
• Type: boolean
• Required: No
• Default: False

Note: Select runDeduplication to run deduplication on the documents within this import, and to suppress duplicates. This process will use the deduplication settings for Ingestions.

The following is an example of how to use these parameters.

Sample mutation:

mutation MySampleMutation {
  importJobCreate (
    caseId: 5,
    input:
    {
      level: ”Imports“,
      docsPerLevel: 1000,
    }
  )
  {
    rdxJobId
  }
}

Sample results:

{
  ”data“: {
    ”importJobCreate“: {
      ”rdxJobId“: 52094
    }
  }
}

Assign sequential document IDs in an import job

The importJobCreate mutation now contains parameters for assigning sequential document ID values for documents in the job.

• Name: documentIdType
• Valid values: Sequential or Existing
• Required: No
• Default: Existing

Note: Use a value of Sequential to have the application reassign document ID values for the documents within this import. Assignment of document IDs uses the provided prefix beginning with the next available document ID number matching that prefix and incrementing by 1 for each document.

• Name: documentIdPrefix
• Type: String
• Required: No

Note: This is static text that appears at the beginning of each document ID only when using Sequential for the documentIdType option. If you do not provide this option, the application will use the document ID prefix setting from the Ingestions default settings.

When the documentIdType option is Sequential, the job generates a document ID for all documents within the job. The generated ID will consist of a prefix from documentIdPrefix and a number value padded to nine digits beginning with the next available number in the case with the same prefix.

Document source and attachment relationships generate using the references in parentId based on the provided document ID values. If using sequential renumbering, document source and attachment relationships will generate only based on the parentId references within this job. Documents will not attach to prior existing documents.

If the document contains only one page, the page label will match the document ID. For documents containing multiple pages, the page labels update as DocID-00001, DocID-00002, DocID-00003, consecutively to the last page.

For files that are in pages, the page file name will match the existing page label such as DocID-00001.tif, DocID-00002.tif, and so on. For files not in pages, the file name appears after the document ID.

The following is an example of how to use these parameters.

Sample mutation:

mutation MySampleMutation {
  importJobCreate (
    caseId: 5,
    input: {
      level: ”Imports“,
      docsPerLevel: 1000,
      documentIdType: Sequential,
      documentIdPrefix: ”Doc_“
    }
  ) {
    rdxJobId
  }
}

Sample results:

{
  ”data“: {
    ”importJobCreate“: {
      ”rdxJobId“: 52094
    }
  }
}

Transfer files from S3 in importJobCreate mutation

The importJobCreate mutation now contains parameters to transfer files from S3.

• Name: fileTransferLocation
• Valid values: AmazonS3 or Windows
• Required: No
• Default: Windows

Note: The default is Windows. When selecting Windows, the files copy from the file repository designated for Images under the import\<case name> folder. When selecting AmazonS3, this mutation returns information needed to access the S3 bucket.

These Options parameters will allow you to request transfer of the following S3 return values within the fileTransferLocationInformation parameter:

• accessKey
• secretAccessKey
• token
• repositoryType
• regionEndpoint
• bucketName
• rootPrefix
• expiration

Note: When the fileTransferLocation is AmazonS3, the mutation copies the files from the Amazon S3 bucket and folder created for the job rather than from the import folder on the agent.

The following is an example of how to use these parameters.

Sample mutation:

mutation MySampleMutation {
  importJobCreate (
    caseId: 5,
    input:
    {
      level: ”Imports“,
      docsPerLevel: 1000,
      fileTransferLocation: AmazonS3
    }
  )
  {
    rdxJobId
    fileTransferLocationInformation
    {
        accessKey
        secretAccessKey
        token
        repositoryType
        regionEndpoint
        bucketName
        rootPrefix
        expiration
    }
  }
}

Sample results:

{
  ”data“: {
    ”importJobCreate“: {
      ”rdxJobId“: 52095,
      ”fileTransferLocationInformation“: {
        ”accessKey“: ”ASIAYUKNL7WXY7M6WUPX“,
        ”secretAccessKey“: ”zr/zys9ph/XOL6RMBpHciteQtjZGsgoISuWPjkBk“,
        ”token“: ”FwoGZXIvYXdzEIr//////////wEaDJ4HkSGCNHD9DJAdaiK7A9k2p8mOMfvgDZMg19Bc5Rmd+/aFCXdS0sWjPUW1/vg6XG35Pr/ja2lW5xfGn2jzYYrMPif1NjfI1NG6Q7cm5TgtOeDTRPnmhhmGj06CehuuitjQmeLqKwljEv48yXVW6c2UIlCAZ120sYLLUvp7iTMXdaSJ3eJiA4/UyZ3Hv4X4wgZghI6ejH2ErxNuIvmA3rjfM+LEZYJhC92nb48E07l1Y2VWvEWd12neZQ+IJB3lxGaZYX9NA0CRK931M/sZ1AlG0ZWcq0jeDO+gIhvff4Hqr1JMoUnCNxF0o/rG2X5qIlbtCK0oCd3SIJ3VbIqIf5hFKCBdy300QqTYZmtDdTszWpuOklVp2IMpmfjXAtiy9HG8BGdiIzxr9Q9LFaSx4tco9vCZxEftjme/6Iqs93A5fFg7+SQCLYZWUih+e/lSg3ojLlVnU3YqnMkxJLO6WsZY2SgLEdcZAPX+1lCIrycw4HqLKAOANt9osBsXWPHPN94gJ68srjVy/ifPHMtaDwahv0G6orMg/GcFYsup+Py2kDwNsKGug48VMeNLRFYCpJI5QNovawSsLQEBgtXJdw5RrhkuTO1SGCh4KOSul4cGMi2AHFGCk5XzhSXQwxXQe/Et42atr+FdokUajB64TLLBJquDkJ8uY4QPCg4/Fv4=“,
        ”repositoryType“: ”AmazonS3“,
        ”regionEndpoint“: ”us-east-1“,
        ”bucketName“: ”test-bucket-nuix-xfer“,
        ”rootPrefix“: ”xfer/Nuix_Discover_61644698-e292-4cb4-b971-af44da2e89a7“,
        ”expiration“: ”2021-07-08T04:33:40Z“
      }
    }
  }
}

Generate levels based on Document ID in importJobCreate mutation

In the importJobCreate mutation, there is a LevelBased option within the documentIdType field. When creating an import job that is LevelBased, the specified docId will be the selected levels, with each separated by the character indicated in the levelSeparator field. After the last level, each document will contain a levelSeparator character along with a sequential padded number.

For example, if you load three documents to the Imports/API/0001 level, and the levelSeparator is the period character, and the levelBasedPadding is set to the number four, the docId values will result in Imports.API.0001.0001, Imports.API.0001.0002, and Imports.API.0001.0003.

Note: The levelSeparator value can only be a single character and must be allowable in a docId. When not entering a character, the default character is a period. The levelBasedPadding value can only be between 3 and 6. When not entering a value, the default is 4.

Sample mutation:

mutation MySampleMutation {
  importJobCreate (
    caseId: 5,
    input: {
      levelSeparator: ”.“,
      levelBasedPadding: 4,
      documentIdType: LevelBased,
      level: ”Imports/API/0001“
    }
  ) {
    rdxJobId
  }
}

importJobS3Refresh mutation to refresh S3 credentials

The importJobS3Refresh mutation allows you to refresh credentials for an S3 folder created as part of an import job. These credentials expire after 12 hours. However, it is possible that transfer of files will continue past this time frame.

The importJobS3Refresh mutation passes the caseId and rdxJobId that allows you to look up the folder information. The mutation also passes the original accessKey and the original secretAccessKey that validate and match the originally provided keys as an additional security measure.

The following describes the mutation and parameters:

• importJobS3Refresh: Obtains new file transfer location information for an existing import job.
• accessKey (parameter): Uses the accessKey value previously returned for this import job.
• secretAccessKey (parameter): Uses the secretAccessKey value previously returned for this import job.

If there is no S3 information for the provided job ID, the application returns the following error: There is no information available for this rdxJobId. If the accessKey or secretAccessKey does not match, the application returns the following error: The keys provided do not match the keys for this rdxJobId.

The following is an example of how to use these parameters and the possible returned data.

Sample mutation:

mutation MySampleMutation {
  importJobS3Refresh (
    caseId: 5,
    rdxJobId: 1040,
    accessKey: ”AEK_AccessKeyId_Old“,
    secretAccessKey: ”AEK_SecretAccessKey_Old“
  )
  {
    rdxJobId
    fileTransferLocationInformation
    {
        accessKey
        secretAccessKey
        token
        repositoryType
        regionEndpoint
        bucketName
        rootPrefix
        expiration
    }
  }
}

Sample results:

{
  ”data“: {
    ”importJobS3Refresh“: {
      ”rdxJobId“: 1040,
      ”fileTransferLocationInfo“: {
        ”accessKey“: ”AEK_AccessKeyId“,
        ”secretAccessKey“: ”AEK_SecretAccessKey“,
        ”token“: ”AEK_SessionToken“,
        ”repositoryType“: ”AmazonS3“,
        ”regionEndpoint“: ”AEK_Region“,
        ”bucketName“: ”AEK_Bucket“,
        ”rootPrefix“: ”AEK_JobPrefix“,
        ”expiration“: ”2019-11-27T07:04:29.601994Z“
      }
    }
  }
}

Populate All Custodians, All Evidence IDs, or All File Paths

When using the importJobAddDocuments mutation, the mutation will add any uncoded values to the document if importing the fields array for a document with a name value of All Custodians, All Evidence IDs, or All File Paths, and the action field is set to InsertUpdate or Append.

Note: Users cannot delete the All Custodians, All Evidence IDs, or All File Paths values from a document using the importJobAddDocuments mutation.

The following is an example of how to add the All Custodians value to the name field for a document using the importJobAddDocuments mutation.

Sample document details mutation:

mutation SampleDocumentDetails{
  importJobAddDocuments(caseId: 5,
  input: {
    rdxJobId: 52080,
    documents: {
      documentId: ”ACTEST_00000001“,
      fields: {
        name: ”All Custodians“,
        action: Append,
        values: ”Sample Custodian“
      }
    }
  }){
    documentCount
  }
}

Sample mutation results:

{
  ”data“: {
    ”importJobAddDocuments“: {
      ”documentCount“: 1
    }
  }
}

Import binders using the importJobAddDocuments mutation

The importJobAddDocuments mutation contains a binders object allowing users to populate existing binders as well as create new binders. If the user provides a binder value that matches an existing binder, the mutation will add the document to the existing binder. Otherwise, it creates a new binder. New binder permissions are set as shared, has no security overrides, and are not mobile. The mutation will not create a new binder if the name already exists.

Sample mutation:

mutation MySampleMutation{
  importJobAddDocuments(caseId: 4070,
  input: {
    rdxJobId: 4128,
    documents: {
      documentId: ”ACTEST_00000001“,
      binders: {
        values: [”Binder 1“,”Binder 2“]
      },
      fields: {
        name: ”All Custodians“,
        action: Append,
        values: ”Custodian from API“
      }
    }
  }){
    documentCount
  }
}

Import issues

The importJobAddDocuments mutation contains an issues object allowing users to create new and populate existing issues. To add documents to an existing issue, the user must provide an issue value matching an existing issue. Creating a new issue occurs when the provided issue value does not match any existing issues. Top-level issues will not have any assigned permissions.

Note: The issue values field should contain the full issue path, where the backslash or forward-slash characters indicate the issue depth, as shown in the following sample mutation.

Sample mutation:

mutation MySampleMutation{
  importJobAddDocuments(caseId: 4070,
  input: {
    rdxJobId: 4128,
    documents: {
      documentId: ”ACTEST_00000001“,
      issues: {
        values: [”Top Issue/subissue 1“,”Top Issue/subissue 2“]
      },
      fields: {
        name: ”All Custodians“,
        action: Append,
        values: ”Custodian from API“
      }
    }
  }){
    documentCount
  }
}

Identify page number when applying annotations

The importJobAddDocuments mutation has an additional field for identifying the page number locating applied annotations called filePageNumber. This field must contain a positive integer and must be within the range of total pages contained within the document. For example, if the document is a 5-page PDF, the filePageNumber field can contain any number between 1 and 5. If the filePageNumber value is set to 2, the annotation appears on the second page of the PDF.

Note: The filePageNumber field replaces the use of the filename field.

Sample mutation using the fileName field:

mutation MyOldSampleMutation {
  importJobAddDocuments (
    caseId: 5,
    input: {
      rdxJobId: 38
      documents: {
        documentId: ”Annotation_00000001“,
        pageaction: InsertUpdate,
        pages: {
          pagenumber: 1,
          path: ”\\Annotation_00000001.pdf“,
          pagelabel: ”Annotation_00000001“
          },
        annotations: {
          fileName: ”Annotation_00000001.pdf“,
          pageNumber: 2,
          type: REDACTION,
          name: ”Attorney-Client Privilege“,
          label: ”Attorney-Client“,
          color: BLACK,
          x1: 100,
          x2: 400,
          y1: 100,
          y2: 400
        }
      }
    }) {
    documentCount
  }
}

Sample mutation using the filePageNumber field:

mutation MySampleMutation {
  importJobAddDocuments (
    caseId: 5,
    input: {
      rdxJobId: 38
      documents: {
        documentId: ”Annotation_00000001“,
        pageaction: InsertUpdate,
        pages: {
          pagenumber: 1,
          path: ”\\Annotation_00000001.pdf“,
          pagelabel: ”Annotation_00000001“
        },
        annotations: {
          pageNumber: 1,
          filePageNumber: 2,
          type: REDACTION,
          name: ”Attorney-Client Privilege“,
          label: ”Attorney-Client“,
          color: BLACK,
          x1: 100,
          x2: 400,
          y1: 100,
          y2: 400
        }
      }
    }) {
    documentCount
  }
}

Import document notes

The importJobAddDocuments mutation has a notes field, that is an array, for specifying what notes will populate in the document.

Required fields:

• Id: A unique integer value assigned to each individual note within a document.
• noteText: The text of the note.

Optional fields:

• category: A category identifying the note. If the entered category does not already exist, the new value creates a new category. When providing no new value, the category is set to Uncategorized.

• userName: The name of the user who created the note. The userId automatically populates with the note when the provided name matches a known user. Otherwise, the note assignment is set to the user performing the import.

• dateStamp: The date of the notes last modification. If left blank, the date populates with the current date and time.

• isPrivate: Indicates whether the note is a private note.

• parentNoteId: The ID of the parent note for a note that is a reply.

• noteTextHtml: Contains the text of the note with the HTML formatting.

• isAnnotation: Indicates if the note is an annotation that appears on a specific page of the document.

• pageNumber: For notes that are annotations, this value indicates the page record on which the note is located.

• filePageNumber: For notes that are annotations, this value indicates the page of the file on which the note is located.

• Coordinates:

• x1: The x1 coordinate for the note.

• x2: The x2 coordinate for the note.

• y1: The y1 coordinate for the note.

• y2: The y2 coordinate for the note.

Sample notes mutation:

mutation MyNoteSampleMutation {
  importJobAddDocuments (
    caseId: 5,
    input: {
      rdxJobId: 300,
      documents: {
        documentId: ”Annotation_00000001“,
        pageaction: InsertUpdate,
        pages: {
          pagenumber: 3,
          path: ”\\Annotation_00000001.pdf“,
          pagelabel: ”Annotation_00000001“
        },
        notes: {
          id: 10,
          noteText: ”Sample note text“,
          x1: 10,
          x2: 20,
          y1: 10,
          y2: 20
        }
      }
    }) {
    documentCount
  }
}

Import chatHistoryStart

The importJobAddConversations mutation contains a chatHistoryStart field that identifies the date and time of a participant’s earliest access to messages in a chat. The chatHistoryStart field is optional, and if provided, all conversation records that are part of the same overall conversation will have the same value for a participant.

Sample chat participant mutation:

mutation MyChatMutation {
importJobAddConversations (
  caseId: 5,
  input: {
    rdxJobId: 10,
    conversations: {
      conversationId: ”Conv123456“,
      participants: [
        {
          id: ”test1@nuix.com“,
          chatHistoryStart: ”2020-02-03T13:49:06.846Z“
        }
        ],
      channelName: ”TestChannel“,
      documentId: ”DocID00001“,
      fields: {
        name: ”Custodian“,
        values: ”Test1“
      }
    }
  }) {
    conversationCount
  }
}

Sample mutation:

mutation MySampleMutation{
  importJobAddDocuments(caseId: 4070,
  input: {
    rdxJobId: 4128,
    documents: {
      documentId: ”ACTEST_00000001“,
      issues: {
        values: [”Top Issue/subissue 1“,”Top Issue/subissue 2“]
      },
      fields: {
        name: ”All Custodians“,
        action: Append,
        values: ”Custodian from API&ld”quo;
      }
    }
  }){
    documentCount
  }
}