Cora Knowledge Center


Define QC Stage Settings

Some cases in Cora OpsManager are sent to QC phase.  

The following parameters need to be taken into consideration for QC Phase:

  • The logic based on which the system will decide if the case should be sent to QC.
  • QC parameters (fields).
  • General setting (fail QC go to originator, audit is blocking).

Logic to send case to QC

The OOTB workflow calculates whether a case should go to QC or not according to the “audit sample level” that is defined in the PlatformConfig lookup. Based on this number the system randomly picks a number between 1-100. If the chosen number is less than or equal to the specified <audit sample level>, the case is sent for QC.  If the audit sample specified is zero, no case goes to QC.

Based on client need, you may duplicate the OOTB workflow, save it with new name, and configure it with different QC logic. Then, paste the new workflow spaceguid in AuditCalculatorWorkflowId field in PlatformConfig lookup.

Create QC Forms

To create a view to hold the QC fields:

  1. Create a new workflow.
  2. Add Form activity.
  3. Create your QC views that must have:
    1. Edit view
    2. Read only view 


If there is more than one QC view, create a Host view that will hold the reference to all other views, and show them based on your logic. Set this view in the PlatformConfig.


  1. Go to ICM Data Model > PlatformConfig.
  2. Write the full path of your Edit QC view in “QA Edit View Path”.
  3. Write the full path of your Read only QC view in “QA Read Only View Path”.

Disabling the Pass/Fail buttons according to some conditions

Use the following code in your QC forms, if you want to disable/enable the pass button based on some conditions:

var btnPC = $find($sq('[id$="cmdSubmitAction"][value="QC Passed"]')[0].id)
       if(your condition for enable the button)   

Define QC General Settings

The below mentioned QC settings are made on the PlatformConfig lookup:

  • AuditIsBlocking: determines whether the case can continue to pending closure status in parallel to the QC task, or only after QC passed.
    • If blocking – in case of pending closure, and audit is needed, the status changes to “With QA”. If QA pass, the status is “Pending closure”, if QC fails, the status is “Audit Correction”. 
    • If not blocking – in case of pending closure, the status is “pending closure”. The findings of the audit are not relevant to the closing of the case.
  • FailedQAReturnsToOriginator:  determines whether the processor who initiated “Pending closure” gets the case back when QA fails or, the case will return to the whole team.