TES
Integrating ProcessMaker Transfer Credit Evaluation (TCE) with CollegeSource Transfer Evaluation System (TES) for Course Evaluation
Contact:
Please work directly with your assigned Account Executive and Solutions Consultant.
Released/Updated:
2025-05-20
Integration Use Case: Verifying Courses and Retrieving
Equivalencies
ProcessMaker’s Transfer Credit Evaluation (TCE) solution automates how institutions assess incoming transfer credits. A critical integration use case is checking if a transferred course exists in CollegeSource Transfer Evaluation System (TES) and retrieving any established equivalency for that course. This ensures that student transcripts are evaluated accurately against the institution's transfer rules. In practice, the workflow needs to: (1) verify the course information (to avoid OCR or data entry errors), and (2) determine if an equivalency is already defined in TES. If an equivalency exists, it can be immediately presented; if not, the system should trigger an evaluation process to create a new equivalency. This reduces manual effort, errors, and turnaround time by leveraging TES’s database of course data and equivalencies.
CollegeSource TES is a repository for course information and transfer equivalencies used by many colleges. It provides a Web Service API (available as a premium add-on) that allows external systems to search course data and even create or query equivalency records in real-time. ProcessMaker, on the other hand, is a BPM/workflow platform that can orchestrate the transfer credit evaluation process end-to-end. ProcessMaker’s platform offers integration capabilities (via Data Connectors, scripts, and REST APIs) to connect with external systems, enabling it to call TES’s APIs as part of an automated workflow. Notably, the ProcessMaker Platform itself exposes a comprehensive RESTful API (OpenAPI-compliant) for its own operations. This means external applications or portals could also initiate or interact with the TCE workflow programmatically (for example, to start an evaluation request or retrieve results), though the primary focus here is how ProcessMaker calls out to TES.
Integration Architecture Between ProcessMaker and TES
At a high level, ProcessMaker (TCE) and CollegeSource TES communicate via web service calls. ProcessMaker acts as the client, sending requests to TES’s API endpoints and processing the responses as part of the workflow. The architecture involves the following components:
ProcessMaker TCE Workflow: The ProcessMaker engine (hosted in the cloud) runs the transfer credit evaluation process. It includes automated tasks (API calls, data processing) and user tasks (for manual review/approval when needed). Using its Data Connector feature or script tasks, ProcessMaker can connect to external REST/SOAP APIs as part of a process . In this integration, ProcessMaker uses those capabilities to call TES’s web services. Secure credentials (such as the TES API Access Key) are stored in the ProcessMaker configuration to authenticate these calls.
CollegeSource TES API: CollegeSource provides a Web Service API suite for TES . (Note: Institutions must have the TES API subscription enabled) The API is typically exposed via HTTPS endpoints (the TES documentation references a service at bws.collegesource.com). Under the hood, these are SOAP-based web service calls (accessible via an .asmx endpoint) with defined methods like GetlnstitutionByOPEIDCode, GetCourseByInstitutionIDCourseCodeMonthYear, GetEquivalency, etc. ProcessMaker’s connector can consume these services either by SOAP or REST calls (for example, by sending appropriately formatted XML requests, or by using any provided REST interface if available). Through the API, ProcessMaker can query TES in real time to validate course data and retrieve or update equivalencies.
User Interface (Student or Administrator): The end-user (which could be a prospective student uploading a transcript, or an admissions officer) interacts with the ProcessMaker front-end (e.g., a web form). They provide input such as the institution previously attended and courses completed. This input is created using the transcript extraction capability of ProcessMaker OCR. ProcessMaker then triggers the integration logic. The user ultimately sees the results in an easy-to-understand tabular format.
In summary, ProcessMaker and TES form a request-response integration: ProcessMaker sends TES a course inquiry, TES responds with course or equivalency information, and ProcessMaker uses that data to drive the next steps.
Data Flow: How the Integration Works
The integration follows a logical sequence of steps to achieve the use case. Below is a typical data flow for verifying a course and retrieving its equivalency through ProcessMaker and TES:
Step 1: Initiation of Evaluation
The process starts when a student or staff member submits a transfer credit evaluation request (e.g., a student uploads their transcript or enters course details in a ProcessMaker form). The submission includes the source institution (where the course was taken) and the course identifier (course code, and term or year taken). ProcessMaker then begins an automated sequence to handle this request.
Step 2: Institution Identification (TES API)
To query TES, the first requirement is the InstitutionID that TES uses internally to identify the source institution. Often the student will provide the institution name or perhaps a code. ProcessMaker uses TES API's “lookup” calls to find the exact Institution ID. TES offers multiple ways to get an InstitutionID: for example, by OPEID code or CEEB code, or by institution name and location . In this step, ProcessMaker issues a request like GetInstitutionByOPEIDCode or GetinstitutionByNameCityState to TES, including the AccessKey!D (API credential) and the known identifier (OPEID, CEEB, or name) of the source school. TES returns the InstitutionID in its response. (TES advises not to store InstitutionIDs long-term since they can change; it’s best to look them up as needed .)
Step 3: Course Verification — “Does the course exist?”
Once the InstitutionID is obtained, ProcessMaker calls the TES API to verify the specific course. The key API here is GetCourseByInstitutionIDCourseCodeMonthYear. ProcessMaker supplies the Access
Key, the InstitutionID from step 2, the course code (e.g., “ENGL 101”), and the month/year
when the course was taken (this helps TES select the correct catalog entry if courses have
changed over time). TES looks up the course in its database.
If the course is found, TES returns details including the course’s unique CourselD in TES, the course code, and the official course title . For example, TES might respond with something like CourselD=12345, CourseCode="ENGL 101’, CourseTitle=“English Composition |” for that institution’s course. This confirms that the course is recognized in TES. ProcessMaker will then proceed to the next step.
If no course is found, TES’s response will indicate “No Course Found” . This could mean the course code was invalid or not in TES’s data (possibly due to a transcript OCR error or a truly new course). In this case, ProcessMaker can flag an error or route the case for manual review. (The integration could prompt an admissions officer to double-check the transcript or course information.) There’s little point in checking equivalencies if the course itself isn’t recognized; thus, a course not found typically ends the automated path (requiring human intervention to resolve the data issue).
Step 4: Check for Existing Equivalency
Using the course information, ProcessMaker next calls the TES API to determine if an equivalency is already established for this course. TES offers a Check Equivalency call (GetEquivalency) that can search for an exact match equivalency in the TES database . This requires providing the sending course details (Send InstitutionID and one or more Send CourseCode fields) and the target (receiving) course details if known . In a simple scenario, ProcessMaker can check for any equivalency where the sending course matches the one we're evaluating and the receiving institution is our institution. If the ProcessMaker workflow knows the target institution (typically itself) and perhaps has a list of its own course codes, it could supply both sides to GetEquivalency for a precise match. Alternatively, TES’s GetEquivalencyListBySendInstitution call can retrieve all equivalencies for a given sending institution (and can be filtered by course code) . This latter approach can be used to find if any equivalency exists for the incoming course without knowing the target course upfront — the response would list equivalency records (CourseEquivalencylDs).
In either case, if an equivalency is found, TES will return an EquivalencylD for it . For example, if TES knows that “ENGL 107 from Old College = ENG-1100 at Our University”, the API call would yield the Equivalency!ID of that mapping.
Step 5: Retrieve Equivalency Details
If an EquivalencyID was obtained in step 4,ProcessMaker can fetch the full details of that equivalency using GetEquivalencyDetailByEquivalencyID . TES will return all information about the
equivalency, including the effective date range, who created it, any notes, and crucially the
mapping of sending course(s) to receiving course(s) . For example, the data might show:
Sendinstitution=Old College, SendCourseCodel=ENGL 101, Receivelnstitution=Our
University, ReceiveCourseCodel=ENG 1100, plus maybe credits or notes. Armed with this
data, ProcessMaker can then present the equivalency result to the user. This completes the
happy path — the student gets an instant answer because the equivalency was already
known in TES.
In many real cases, a good portion of common courses will have existing equivalencies (institutions continuously build their equivalency library). ProcessMaker's integration effectively automates the lookup of those rules. ProcessMaker’s TCE solution's “Automatch” can instantly compare incoming courses against the institution’s equivalency tables — TES is often the source of those tables, so this integration delivers that capability by querying TES’s data in real time.
Step 6: Handling No Equivalency -— Initiating a New Evaluation
If TES indicates that no equivalency exists for the course, the integration then turns to creating a new evaluation. This is where ProcessMaker's workflow really adds value: it can automatically kick off the process to get an equivalency established.
Using ProcessMaker to Evaluate and Then Update TES: In all implementations, the institutions prefer to handle the review within the ProcessMaker workflow itself (for example, assigning a task to a faculty member to evaluate the course). In this case, ProcessMaker can gather the necessary information (course description, syllabus, etc. — it could even use Al to retrieve the course description text for the evaluator’s convenience). The faculty or registrar could then approve an equivalency within the ProcessMaker interface. After approval, ProcessMaker can use the SetEquivalency API to programmatically create a new equivalency record in TES . The SetEquivalency call requires details such as the sending CourselD(s) and the equivalent receiving CourselD(s) at the institution, along with metadata like effective dates, notes, and the user ID who is creating it . Upon success, TES returns a new EquivalencyID, meaning the equivalency is now stored in TES’s database . ProcessMaker could then finalize the case by informing the student of the outcome. Using this approach, ProcessMaker controls more of the workflow (including the human approval steps) and then updates TES to keep the systems in sync.
Relevant API Calls and Examples
To summarize, here are the key API calls involved in the ProcessMaker-TES integration and examples of their usage:
Institution Lookup: GetinstitutionBy... (OPEID, CEEB, or Name/City/State). Usage: Provide an identifier for the school and get back an InstitutionlD. Example: Get Institution by Name — Input: “Old College, Springfield, NY” > Output: InstitutionID = 5678.
Course Lookup: GetCourseBylnstitutionIDCourseCodeMonthYear — Verifies a course at the given institution and returns a CourselD if found. Example Request: (pseudo-REST/URL format for illustration)
Unset
GET /GetCourseBylnstitutionIDCourseCodeMonthYear?AccessKeylD=&InstitutionID
=5678&CourseCode=ENGL%20101&Month=9&Year=2022Example Response:
Unset{
"CourselD": 12345,
"CourseCode": "ENGL 101",
"CourseTitle": "English Composition |"
}If the course does not exist, the response might indicate an error or empty result (e.g., "No Course Found" message) .
Check Equivalency: GetEquivalency — Searches for an existing equivalency with exactly the given combination of send and receive courses . Requires specifying the course codes on each side. Returns an EquivalencylD if an exact match is found. Example: Input: SendIinstitutionID=5678 (Old College), SendCourseCodel="ENGL 101", ReceivelnstitutionID=1000 (Our Univ), ReceiveCourseCodel="ENG 1100” > Output: EquivalencylD = 4444 (indicating that this precise equivalency exists in TES).
List Equivalencies by Institution: GetEquivalencyListBySendinstitutionByAccount — Retrieves all (or filtered) equivalencies for a given sending institution from your TES account . This can be used to find if any equivalency exists for a course without specifying the target. The call supports filters by status or specific course codes. It returns a list of equivalency records (IDs and basic info). (This is useful if you want to, say, get all equivalencies for “Old College” and then search the result for the course of interest, in cases where you might not know the target course code.)
Equivalency Detail: GetEquivalencyDetailByEquivalencyID — Given an EquivalencyID, returns full details of the equivalency . Example Response Fields: EffectiveDateBegin, EffectiveDateEnd, Sendinstitution Name/City/State, SendCourseCode(s), Receivelnstitution Name/City/State, ReceiveCourseCode(s), PublicNote, PrivateNote, etc. . This data would be parsed by ProcessMaker and possibly displayed in a user-friendly format in the workflow UI or in a generated report.
Create Equivalency: SetEquivalency — Creates a new equivalency record in TES outside of the normal interface . Example: Input: AccessKeylD, CreateUserlID=110, SendCourselD1=12345 (Old College ENGL 101), ReceiveCourselD1=67890 (Our Univ ENG 1100), EffectiveDateBegin="2023-O01-01", PublicNote="Auto-approved via TCE workflow”. > Output: EquivalencylD = 4450 (new equivalency created). This would instantly add the rule “Old College ENGL 101 = Our Univ ENG 1100” into TES’s database of equivalencies, so it can be used for future evaluations or shown on TES public-facing transfer guides .
All TES API calls require authentication (the Access Key ID) and are subject to TES’s permissions (the API only exposes data from the institution’s own account). CollegeSource’s Getting Started guide and API documentation provide parameter details for each call and sample processes . It’s important to handle error responses (e.g., “course not found” or no equivalency) in the ProcessMaker workflow to decide the next action (as shown in the flow diagram above).
On the ProcessMaker side, invoking these API calls can be done in a few ways. ProcessMaker’s Data Connectors allow designers to configure connections to external APIs (REST or SOAP) and then call those connectors within a process without writing code . For example, one could set up a SOAP data connector for the TES WSDL and then use the data connector task in the BPMN modeler to call “GetCourseBylnstitutionlD...” and retrieve the result. Alternatively, one could use a Script task in ProcessMaker: for instance, writing a small script (NodeJS or PHP depending on the platform version) to send an HTTP request to the TES API endpoints and parse the JSON/XML response. ProcessMaker's Al supported scripting environment would allow using environment variables for the TES credentials and then storing the response data into process variables for use in subsequent tasks (like decision gateways or for display in forms).
To illustrate, a pseudocode snippet for a ProcessMaker Script task might look like:
Unset
// Pseudocode example inside a ProcessMaker Script task
const instResponse = callTesApi(‘GetInstitutionByNameCityState’, {
name: requesterInstitutionName,
city: requesterInstitutionCity,
state: requesterInstitutionState
3);
if (linstResponse.|nstitutionID) {
// handle error: institution not found
}
const instld = instResponse.I|nstitutionID;
const courseResponse =
callTesApi(‘GetCourseBylnstitution|IDCourseCodeMonthYear’, {
InstitutionID: instld,
CourseCode: courseCode,
Month: courseMonth,
Year: courseYear
});
if (IcourseResponse.CourselD) {
// course not found, end or manual intervention
}
const courseld = courseResponse.CourselD;
// Check for existing equivalency
const equivResponse = callTesApi(‘'GetEquivalency’, {
SendinstitutionID: instld,
SendCourseCode!l: courseCode,
ReceivelnstitutionID: MY_INST_ID,
ReceiveCourseCodel: targetCourseCode // if known or loop through possible
});
if (equivResponse.EquivalencyID) {
// Equivalency exists — retrieve details
const details = callTesApi(‘(GetEquivalencyDetailByEquivalencyID’, {
EquivalencyID: equivResponse.EquivalencylD
});
// use details to inform user
selse {
// No equivalency — create evaluation task
callTesApi(‘SetEvaluationTask’, {
CreateUserID: API_USER_ID,
AssignedUserlD: EVAL_FACULTY_ID,
SendinstitutionlD: instld,
SendCourselD1: courseld
});
// notify staff or pause for evaluation completion
}In a real implementation, callTesApi would handle the HTTP(S) request/response. The above is simplified to illustrate logic flow. Also, real code would need to catch network errors or API errors (e.g, invalid credentials or TES downtime).
On the security side, all communications to TES’s API occur over HTTPS. The Access Key acts as the authentication (almost like an API token). It’s essential to keep this key secure; in ProcessMaker one would store it in an environment variable or in the Data Connector configuration (which is usually encrypted/secured on the platform). Each API call from ProcessMaker to TES is a discrete transaction — no persistent connection is needed. Given that TES’s API is an add-on service, an institution integrating like this would ensure their TES subscription includes the web service API package.
Conclusion
The integration between ProcessMaker TCE and CollegeSource TES allows institutions to streamline transfer credit evaluations by combining ProcessMaker’s powerful workflow automation with TES’s rich course and equivalency data. In summary:
ProcessMaker orchestrates the process, presenting interfaces to users and handling decision logic. It connects to TES via web service calls to fetch required data in real-time, using either built-in connectors or scripts. ProcessMaker’s own APIs and integration tools ensure it can both call out to TES and be called by external systems, providing flexibility in how the solution is deployed .
TES serves as the authoritative source for course information and existing transfer rules. Through its API, it exposes functionality to search for courses, check for equivalencies, and even create new equivalency records. This enables an automated workflow to leverage all of the institution's transfer knowledge base in TES, without requiring manual lookup.
By verifying that a transfer course exists in TES and retrieving its equivalency (if present) as an automated step, students can get immediate answers on credit transferability — a key factor in enrollment decisions. One case study notes that providing instant, personalized credit evaluations upfront builds trust and helps convert prospective transfer students faster . For IT decision-makers, this integration reduces duplicate data maintenance (using TES as the single source of truth for equivalencies) and minimizes manual data entry errors by validating against TES’s dataset .
For integration engineers, the architecture is robust and extensible: new API calls or changes on either side can be accommodated. For example, if CollegeSource updates their API or adds new calls (say, to support bulk queries or additional data like course outlines), ProcessMaker can be updated to use those. Likewise, if the institution adopts new business rules (like requiring approval from multiple departments), those can be modeled in the ProcessMaker workflow while still using TES for data. The modularity of calling TES’s API means the solution is loosely coupled — each system handles what it’s best at (ProcessMaker for workflow/routing, TES for transfer credit data) via well-defined interfaces.
In conclusion, integrating ProcessMaker TCE with CollegeSource TES creates a powerful end-to-end transfer credit evaluation system. It automates the verification of courses and retrieval of equivalencies (via TES APIs) and seamlessly handles the scenario where no equivalency exists by launching an appropriate workflow (via ProcessMaker tasks). The result is a faster, more accurate evaluation process that benefits staff and students alike — all built on a service-oriented architecture using standard APIs and web services . By following the patterns and examples in the TES Getting Started guide and ProcessMaker’s API documentation, institutions can confidently implement this integration to streamline their transfer credit operations.
Sources:
CollegeSource TES Support — Web Service API Overview , Sample Process: Checking if a Course Exists , Sample Process: Custom Form to Request Evaluation , Equivalency Manager API Calls , etc. (TES Getting Started Guide and API Reference).
ProcessMaker Documentation — ProcessMaker Platform RESTful API , Data Connectors and Integration , ProcessMaker Higher Ed Solution Briefs.
Last updated