This is a General Information article designed to give you a general overview of the Concourse feed process. If you are looking for technical specifications for feeds, consider exploring Construct and Process System Data Feeds or Automated Feed Processing to get started with technical aspects of feeds.

Feeds Overview

1. When running a pilot
   
2. When your number of users and/or courses is less than 100
   
3. When auto-create (for users and/or courses) is an option
   

Feed Construction

The actual feed specification is fully documented in other technical articles within the support center, but we’ll emphasize a few aspects here. First, the most important part to get right with feeds is the external ID. It is how each row in the database is uniquely identified and may be used to tie together the actions of one feed with another. This will always be the first column in each feed and as the key will not be modifiable by subsequent processing. Most every other field (with a few exceptions) can simply be updated by running the feed again.

Next is sequence. The four common feeds generated for Concourse are: User, Course, Section, and Registration. (There are other types but many of the same principles will apply.) The easiest feed to construct is that for Users and where most clients begin. It can be run independently as it does not require any data yet be in the system.

The course feed is also (largely) independent but much more comprehensive. It will include fields like title, subject code, start and end dates, and term. Additionally, critical to implementations using templates and where we often get questions is the use of a CLONE_FROM_IDENTIFIER. If used this tells Concourse from which course (as identified by the course ID) to copy content and settings. This is why a course feed may not always be "independent" as it is possible that it will rely on the existence of another course, whether created manually or from a previous feed run.

The next field in the course feed we typically receive questions about is the use of the IS_TEMPLATE flag. On its own this simply designates a course as a template. However, if a course is cloned as a template from one that is also a template, it will cause them to be "joined." This is how our linked template functionality is enabled.

You’ll also need to be sure that your domain listing includes identifiers that match the CAMPUS_IDENTIFIER and DEPARTMENT_IDENTIFIER fields.

Once your courses are loaded you must run a Section feed to "insert" one or more sections into the syllabus for that course. In most cases you will end up with one corresponding row in your section feed for each row in the course feed, meaning that you’ll end up with one syllabus per course section. More advanced implementations may put multiple sections into a single course, such as when a static "master" syllabus is to used across every instance of a course offered in a given semester.

Another FAQ is how to handle sections for templates. Again in most cases you will insert a single section into each template course with a section Label of "All".

The final major feed is that of Registrations, which ties together users with sections. You will also indicate their role (e.g. Students, Instructors, etc.) when creating this feed.

Feed Sequencing

Once all your feeds are built up one needs to think about the sequence how feeds should be processed. We just noted that a natural pattern is that of (1) User, (2) Course, (3) Section, and (4) Registration. However, based on your template structure it may require some inner iterations of this sequence, such as the subsequent processing of pairs of course and section feeds to first setup an initial course-level template structure and then again for creating the actual instructional syllabi for the term.

Another concept enabled by feeds is template archival. Generally you will have a collection of syllabus templates that are continually updated for future terms. You'll also inherently have all the instructional syllabi delivered to students that were cloned from these templates. However say in addition to these in classroom syllabi you want to take a "snapshot" of all the templates as they stood at the beginning of the term. This could be accomplished through the use of another pair of course and section feeds after changes to templates have been finalized for the term but before instructor editing commences.

Feed Timing

Closely related to sequencing is timing. You may find that some of these feeds need to be run continually, others on a one-time basis. Further still something like the snapshot archival described above could be once a term or even once a year based on when template changes are made and finalized.

Timing is not only about absolute frequency but when within the academic cycle these runs need to take place. Some of the gates to think about include when:

• templates will be updated
• syllabi will be audited
• instructors will first edit syllabi
• students should be able to access syllabi
• how these timings interact with other campus systems

 which in turn may translate into when: 

• templates can be cloned
• archival can take place
• permissions need to be updated
• instructors can begin editing
• students can begin viewing

and so forth. As you can see it’s probable that process and policy decisions need to be made by Academic Affairs to inform this part of the implementation.

Feed Processing Details

There are two methods for getting feeds into Concourse: manual and automated. As the terms imply manual will mean that you have to log in to Concourse to upload a correctly constructed feed file which is stored on your machine. By contrast, automated feeds are constructed and posted to Concourse using a script against your student information system. This section gives general overview of manual feed processing. To learn more about automated feeds, consider exploring the Automated Feed Processing article in our support center.

Even if you expect to reach a fully automated environment, you will want to stick to a path of increasing sophistication as you build out your feeds. In other words, you might not want to start with automating everything. On one hand determining if your integration is performing as expected is far easier when you can isolate issues to basic feed construction (1), data cleanliness and scale (2), or automation scripting (3). At the same time, depending on your situation, you may come to find that it is easier to continue with manual uploads rather than invest in the technical resources to automatically run feeds.

Therefore, we strongly urge you to take the following, sequential approach to building out your feed processing:

1. The manual creation and upload of sample feed files
2. The manual creation and upload of full feed files
3. The automatic creation and upload of sample feed files
4. The automatic creation and upload of full feed files

When we talk about samples, we mean around the first ten rows of your file, way less than the thousands you will almost certainly have in the full feeds. These first ten will immediately expose whether the file is constructed appropriately quickly and easily. In fact many times that can be created and tested by just filling dummy data in and without the need to generate a report from your SIS.

As always, the sandbox should be your best friend throughout this entire process.