About Record Assignment

The record assignment feature enables records of the following base entities to be assigned to users or teams by defining configurations in the Assignment Group entity:

  • Account
  • Application
  • Contact
  • Inbound Interest
  • Lifecycle
  • Student Alert

Important: The Student Alert - Set Owner as Student's Advisor flow must be disabled before using the Record Assignment feature for updating the records of the Student Alerts entity.

Record assignment can happen:

  • In the admission season at scheduled intervals when applications need to be transferred from a central recruiting agency to a student counselor in a specific territory or to the Admissions team at the applicant’s campus.
  • In real time when customized trigger flows are activated when applicants create records on the portal. The applications can then be assigned to student recruiters in the applicant’s territory who will then engage with the applicant to complete admission processes.

Scheduled record assignment occurs at fixed intervals (every 15 minutes by default) whereas trigger based assignment occurs in real time.

Record assignment is managed using the following entities:

  • Assignment Group – Configurations that shortlist records to be assigned are created in the Assignment Group entity.
  • Assignment Rule – Rules that enable record assignment are specified in records of this entity.
  • Assignment History – Instances of these records log changes to values of fields updated through scheduled or trigger-based record assignment. These records are read-only and are automatically created.
Assignment Group

The Assignment Group entity enables the creation of a configuration that shortlists records of a base entity to be assigned using logic in associated Assignment Rule records. Shortlisting of records happens based on the query in the assignment group record.

Assignment Rule

The Assignment Rule entity enables assignment of previously shortlisted records based on criteria in the associated query.

Example

In the next round of Summer admissions, application records with permanent addresses in the Eastern states and which are currently owned by Parker Roy from the central recruiting agency must be assigned Ian Hass, the admissions coordinator in the Eastern territory.

Records of a selected base entity can be assigned using one of the following methods:

  • User - Records will be assigned to a user selected in the User to Assign field.
  • Team - Records will be assigned to a team selected in the Team to Assign field.
  • Round Robin Assignment - Records are assigned equally to users in a group, in this case the selected user list (which can be static or dynamic). In this framework, administrators can select one of the following assignment methods:
    • Round Robin - Records are assigned to each user in the selected user list in alphabetical order based on the user's first name. The associated user list can be static or dynamic.
    • Weighted Round Robin - Records are assigned to users in a static user list based on the weight assigned to each user. Assignment will start with the user who has the maximum weight and will then pass to the next user in descending order of weight, and so on.
    • Load-based Assignment - Administrators can define a query to retrieve users to who base entity records are currently assigned.
      Record assignment will then begin with the user who has the least number of records, after which assignment will progress to users with a higher count of records, and so on. Record assignment will carry on till all users have the same count of records. Once the load is equal, record assignment will happen from one user to the next user.
    • To view an example of each of the above assignment methods, see Creating an Assignment Rule.

Multiple assignment rule records associated with an assignment group enable institutions to build logic where each assignment rule is associated with a number, i.e., its execution order. Records not assigned after the assignment rule with execution order 1 will pass to the assignment rule with execution order 2, and so on.

Assignment happens at preconfigured intervals or on the occurrence of specific events. For example, an institution can define that record assignment must happen:

  • At intervals configured by an administrator.
  • Based on the occurrence of events such as when:
    • A user creates a contact in the system.
    • A prospective student creates an application on the portal.

By default, record assignment is switched off, i.e., the value of the Publish Status field in assignment group records is set to Draft. This means record assignment logic in assignment rule records will not be triggered. To begin the process of record assignment on the next run of logic, the value of the Publish Status field must be set to Live.

Records that remain unassigned even after all assignment rules are executed will be assigned to the user in the assignment group's Fall Back User field.

Assignment History

Records of the Assignment History entity are read-only and log changes to values of fields updated when record assignment occurs. A new Assignment History record is created for each change in the value of the field. Assignment History records can be viewed in the Assignment History tab that's displayed in the parent assignment group record and in records of the following base entities:

  • Account
  • Application
  • Contact
  • Lifecycle
  • Inbound Interest
  • Student Alert

Error Logging in the Record Assignment Framework

Error logs are created when unhandled exceptions occur in the record assignment framework. For more information, administrators can see Viewing Error Logs.

Parker Roy, the freshman student recruiter at Seagull University, has completed his recruitment activities. He is winding down tasks as the opening term will begin shortly and ownership of student records will transition to Ian Hass, the student counselor at the Eastern campus. To achieve this assignment, the following steps need to be performed:

  1. Create an Assignment Group record, Summer Admissions. It includes a query to shortlist applications that must be assigned to counselors based on the applicant’s permanent address.
  2. In the Assignment Group record, the value Owner must be selected in the Assign To Field. This will ensure that Ian is assigned the application records.
  3. In the Assignment Rule record:
    • Include logic in the query that will assign records owned by Parker to Ian Hass.
    • Specify the execution order record. It indicates the order in which assignment rule records are run.

    The operation to assign records to Ian Hass will occur in the next run of assignment logic. Before that, the Assignment Status in all application records must be set to Pending Assignment.

    It is assumed other logic is not available that will reassign the same records back to Parker Roy.

Notes:

  • In the Default Configuration page, the value in the Record Assignment Batch Size field determines the count of records that will be assigned. For more information about this field, see Default Configurations.
  • Assignment group, assignment rule and assignment history records can only be deleted by users with the CMC – Add On - Delete Permissions security role.
    If an assignment group record is deactivated or deleted, its related assignment rule and assignment history records will also be deactivated or deleted.
  • Behavior of the DOM Status / Application Status field:
    • When account, contact, inbound interest, or lifecycle records are assigned to another owner, the value in their DOM Status field will change from Pending Assignment to Assignment Complete.
    • Records in which the DOM Status field is set to Locked Assignment are not processed when scheduled assignment logic executes.
    • The value in the DOM Status field changes only if record assignment is based on the Owner field. If a field other than Owner (for example, Student Advisor) is configured to be assigned, the operation will progress regardless of the value in the DOM Status field. In such a scenario, scheduled assignment logic will happen only if the field is blank.
    • Scenarios can occur where assignment needs to happen even if the DOM Status field has the value Assignment Complete or the Student Advisor field in the above example needs to be updated again. To enable assignment, the value in the DOM Status must be set to Pending Assignment, and the Student Advisor field must first be cleared.
    • The application and student alert entities have the Assignment Status field that has the same behavior as the DOM Status field in other entities.