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.
Q. I was expecting to see a particular value coming from our SRS but I can see that field is empty, what do I do?
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.
Q. Why are some fields originated in the CRM, not in our SRS?
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.
Q. Is it OK that many fields are empty? Will it still work OK?
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.
Q. How can I edit the values in the list?
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.