Finalsite Open Integration

Integration Method


Finalsite Open integrations are a way to integrate data that is exported from another database such as an SIS or MIS system (one that Finalsite has no direct connection to).  Exports must meet the data requirements described in detail below. If the exports from the source database are able to be generated automatically, we can fully automate the integration, in most cases.

In the deployment of the integration, a Finalsite deployment specialist will ensure that the data in your exports is mapped into Finalsite appropriately and also work to setup the means to pass your datasheets to our servers, securely.  It is important that once the format of the exports is determined, they not be altered.

Sending Datasheets to Finalsite

  1. A Java utility that we can provide you with that will POST updated datasheets to our servers, securely.  This utility can be scheduled in the server/workstation to run on a scheduled basis to check for updated datasheets, and send them to Finalsite.
  2. We can pull the datasheets from an SFTP location that you provide us READ-access to.

Available Datapoints

There are a number of fields that can be populated via the integration.  Most are included in the Data Upload Templates (available in this article).

Data Requirements

  1. File format: Microsoft Excel 97-2003 (.xls), .xlsx, XML, or plain Text (tab-delimited)
  2. Adhere to a file naming convention . The file naming convention will be determined by the types of data that need to be part of the integration and the export capability of the originating system. Examples are
    • faculty data: fs_faculty.txt
    • student data: fs_student.txt
    • parent data: fs_parent.txt
    • classes: fs_classes.txt
    • enrollment (rosters): fs_enrollment.txt
  3. Each individual (student, parent, etc) must have unique, persistent ID (ImportID).
  4. The value to be used as the finalsite ImportID must always be the left-most column AND remain consistent through all exports. Class rosters (enrollments) do not have to meet this requirement.
  5. Column headers may not contain spaces. The only non-alphanumeric characters supported are hyphens and underscores. (e.g. HomePhone / Home-Phone / Home_Phone are acceptable, Home Phone is not).
  6. The contact portion of the export should be arranged so that each column contains a specific “type” (for example, home phone number).
  7. A column may contain one type of data only (for example, if column A contains the home phone number for the first record it may not contain the business phone number for the next record).
  8. All exports must be consistent once Finalsite and the client have signed off on them. This means no data column(s) can be added or removed without working with finalsite to analyze the changes involved.
  9. Departments and locations are supported for faculty, but the department and location names in the faculty export file must be identical to the corresponding department and location in the finalsite Group Manager. A mismatch will cause the faculty member to not be added to the right dept/location (e.g. “Main Build.” in the export file vs “Main Building” in Group Manager)
  10. Data files should not be further modified or manipulated after exporting them from the SIS. This means no changes to column headers or manual edits to the data of any kind are allowed once the file has been exported.
  11. Username support must be decided on a case-by-case basis. We can auto-populate the username data based on the raw data (for example, by concatenating the constituent’s first and last names). Alternatively, you can provide constituent usernames in the export files.
  12. Password synchronization through the integration is not supported. Finalsite recommends allowing users to set their passwords on their initial login.  This should be discussed on a case-by-case basis.

Was this article helpful?
0 out of 0 found this helpful



Please Sign in to leave a comment if you don't see the comment box below.