In the example below, the passive application from our test student Rob Sanderson was received from the university's SITS feed via our Passive API.

The 'Application' tab in green lists all the fields that arrived from SITS, and are searchable. Note that these are just fields from the application and not the applicant, so if you are expecting to see a postcode, email, etc (personal data) that is not here).

Data received in these fields is used to personalise your Applications workflows and touchpoints and also in Application Segments.

You can see further details about the activity on the application on the Activity Log tab, and any Applicant Open Day bookings on the Open Days Bookings tab.

A. Please check with your CRM Project Manager that they requested that field from your university's IT Dept when they set up the API connection. It may indicate that the field is in your SRS and not being passed across, or it is not in your SRS. Either way, your CRM Project Manager can help you.

A. In the example above you will see that the 'year-of-entry' field is originated in the CRM. This is because it can use the Course Code that your SRS sent in and it can retrieve extra information such as the Year Of Entry, etc from the Courses app in Student CRM. Other CRM-originated fields include IDs that get created when the API feed is processed.

A. Yes, it will work OK as not all fields are required. When your university's IT Dept sets up the API connection they will have worked with your CRM Project Manager to agree on which fields should appear. If you want another field added after it has been up and running for a while your university's IT Dept can do this for you.

A. You can't. Those values are received from your university's SRS feed via our Passive API, so all changes have to be made in your SRS, ie: SITS.