Integration is fairly technical in nature so you will want to be sure that your IT department works with you on this task. They should already be familiar with the technologies and processes discussed in this article.

This high value is achieved by pursuing at least one of three integration approaches:

But, before we get ahead of ourselves, the critical question to ask (which should be informed by the preceding template design and administration exercises) is:

For example, if at the beginning of your implementation you plan on using a singular, institutional template, you may be able to rely upon auto-creation for users and courses and therefore not need to process any feeds whatsoever. Alternatively, if you consider the only gateway to Concourse to be the LMS, it can serve as your central authentication and you won’t need to utilize any other methods.

The answers to the question above can vary drastically depending on things like your implementation timeline, available resources, and technical comfortability. Therefore, this article will cover a fairly extensive integrated situation, even though only parts of this may pertain to your implementation.

Access and Capability

The first step to integration is to understand the two dimensions that drive complexity: access and capability.

To get started we’ll talk about access, or through what venues you expect to reach Concourse. In general, you want to make at least two pathways available: authenticated and public. Here is a non-exhaustive list of how one might reach Concourse:

• Direct (internal): Users arrive at the native login page and use a Concourse-specific set of credentials (email + Concourse password).
• Direct (external): Users arrive at the native login page and use centrally administered credentials (e.g. college ID + common password).
• Hosted: Users arrive at a Concourse-specific login page maintained on-campus to then be passed over to Concourse as already authenticated.
• Portal: Users first log in to another system and then choose the Concourse application.
• LMS: Users log in to the LMS and to access the Concourse application.
• Public: Users visit Concourse directly (without logging in) and can search for and access publically available syllabi.

Each of the options listed above, with the exception of "Public," requires an authentication approach. It's important to think about these approaches because you can create different authentication options or methods for different users. For example, you might want Concourse administrators to have the freedom to access Concourse directly using an Internal approach but also have access through the LMS (e.g. this is helpful if they are troubleshooting in courses).

Authentication

Now that you’ve gotten a sense of what your access and capability options are, next we need to discuss authentication options. First, let's define internal versus external authentication:

1. Internal: Users arrive at the native login page and use a Concourse-specific set of credentials (email + Concourse password)
   
2. External: Users arrive at the native login page and use centrally administered credentials (e.ge. College ID + school password)

Here are the access points we discussed above in Access and Capability, sorted by whether they are internal or external authentication methods:

1. Internal: Concourse platform native webpage
   
2. External: Directory, Portal, LTI in the LMS, Single Sign-On
   

Note: Internal authentication cannot be used simultaneously with any of the external (i.e. Directory, SSO, LTI) authentication choices. In other words, a given user account can either be authenticated internally or externally, not both. It is possible however to coordinate the switch from internal to external during the implementation or even production use.

Learning Management System (LMS) and LTI Linking

Leveraging the LMS for authentication and integration is preferred by almost all clients, so let's spend time discussing the option of using the LMS and LTI links, and why you might want to use this option at your institution. While the LMS is technically just another integration/authentication vehicle for Concourse, given its importance to an exceptional instructor and student experience, we call it out separately here.

LMS integration is generally achieved using a specialized standard called Learning Tools Interoperability (LTI). This protocol, specifically designed for ease of integration with learning systems, includes all the information one should need to bring in third-party tools like Concourse into the learning environment. Newer versions of the standard even include support for functions such as grade feedback, though those are not discussed here as they are not pertinent to a syllabus tool. For more information in LTI standards, consider starting with our articles Concourse LTI Integration Specifics and LTI 1.3 Has Arrived.

It's important to start with the two key pieces that allow LMS integration work: the user and the course (or context in LTI-speak). A successful LTI launch in Concourse relies upon the platform being able to understand who the person is and which syllabus to present when the LTI link is clicked within a course. Additionally, an optional third element is a user's role. A user's role (e.g. student, instructor, etc.) is often provided and considered by Concourse if available but not required if you are also utilizing registration feeds in Concourse. Leveraging roles in Concourse helps with centralization and consistency of content because you can set granular viewing and editing permissions for a user based on their role. For more information on this concept, consider reading our article, Group Permissions in Concourse, which outlines all of the defined roles as groups within the platform. 

Another factor to consider that should come out of your template design exercises is just what type of access you want to provide to a syllabus presented in an LMS course. Is it a static syllabus generated from a template for all sections of the same course? Is it a sectional syllabus that instructors build from? Do they author or upload one entirely from scratch? This will largely determine what you need to do in terms of unique course identification.

So, assuming your LMS is LTI-enabled, the next step is to figure out exactly what data it can provide through an LTI launch. This is done by first adding an LTI consumer to Concourse, next setting up a paired LTI tool within a representative course in your specific LMS, and then setting a custom parameter so that Concourse displays debug data. What you’ll be looking for is a value that resembles the user and another that resembles the course. These are likely IDs that you are used to seeing, either because you log in with them, they precede your email, or are the same as what you are loading into the LMS. 

Once you have discovered how your LMS formats and sends user and course IDs, add examples of these and their matching parameters names to your Operating Manual. Additionally, it is just as helpful to jot down any other known formats for user or course IDs, such as what your portal might be using. One hopes they are similar but if not middleware tools like Apidapter exist to help equate them.

 Note: It is also possible to use the LMS as a "Portal" by enabling LTI to consider only the user and not the course. This would be useful if you wanted to provide general Concourse access, say for instructors and students interested in reviewing other syllabi or for Deans and Chairs to audit and report on courses. If this option interests you, consider mentioning it to your implementation team.

Feeds

The final integration option we need to cover is using feeds! You can use feeds to extract data from external systems and "feed" it into the Concourse platform. Feeds are the creation and submission of feed files, or the bulk upload and processing of users, courses, registrations, and even syllabus content. 

Feeds are typically considered the last form of integrating the platform for several reasons. First, saving feeds for "last" allows your institution to focus on authentication. By focusing on authentication first, you give yourself some time to understand the impact of the rest of the decisions made throughout the implementation. Ultimately, the decisions you make with authentication drive the need for either simple, comprehensive, or even no feeds at all in your Concourse platform. Second, by the time you begin exploring feeds, it is likely that you’ve already started to explore Concourse to enter syllabus content and setup at least a part of your domain listing, which means you are already creating users and courses manually. In fact, this might be sufficient for some organizations. Small implementations (e.g. <100 courses per term) may not require the use of feeds at all as the effort in creating and maintaining them may exceed that of manual management. The same may be true with simple implementations (e.g. Concourse Lite or the use of only an institutional template) which can rely on the use of the auto-creation option associated with LMS integration. If you're interested in a way to create users and courses without utilizing feeds, consider exploring Creating Courses and Users Automatically via LTI. Lastly, feeds are relatively easy to add and adjust based on changing needs while other steps of your implementation, such as authenticating users, are significantly more difficult to change later.

1. Overview of Concourse Feeds
   
2. Construct and Process System Data Feeds
   
3. Automated Feed Processing