SLAs - Data Migrations/Loads/Other Support
SLA's are Service Level Agreement Targets.
How fast Interfolio can complete file processing, team projects, general support questions, processing improvement requests, pass through engineering requests, etc. depends on our current workload, availability of resources, current projects, other priorities, etc.
Our goal is to balance these priorities as efficiently as possible. Listed in the table below are our targeted SLAs.
Important: Recurring client file processing is tracked via a shared calendar. If a client plans on sending files on a regular cadence, we ask that they complete the Client Data Survey. This survey helps with understanding what services are supported, planning for recurring loads, and communication to Data Services about non-base data file processing plans.
NOTE FOR CLIENTS: The expectation is that files will include data that can be loaded cleanly into a field that already exists in the database. There is NO EXPECTATION that Data Services will modify the data provided.
Data files MUST meet DATA MODEL standards and comply with the Data Triad: CLEAN, CORRECT, COMPLIANT.
|Type of Request||Days||Target Completion|
|Base data sets: Unit, Faculty, Faculty Classification, Current Position, Secondary Unit, Prefix, Courses, Courses Taught, Scholarly Outlet Lists, Committees, Support Accounts.||None||The client is expected to manage the loading of base data set files either by using the autoload feature or the UI administrative feature.|
|Database Clone - to any non-production database||< 1||
1 day (24 hours) from the time of ticket triage. (Typically 10:30 AM - businesss days) for any clone to a non-production database.
After cloning, all users except for those who are Level 1 administrators will have their login disabled in the target database.
|Database Clone - dev to prod||~1||
Development to Production - ‘Go Live’:
This request can be planned.
Please submit a request with the specific date/time for the clone.
After cloning, all users in the production database will be set to log in. Users in the source database will remain unchanged.
|New / Recurring File Processing (non-base data)||<30||
The general target for completion is 30 days but the team target is < 15 days.
New files are those that require additional triage for file format, mapping to section fields, writing the code for processing, and time for the file to load.
Recurring files are likely to fall into the team target of < 15 days unless the file has been modified and the process set up has to be modified.
|System Modifications||<30||User account issues, auto load triage, file processing triage, etc.|
|Data Migrations: Activity Insights (Digital Measures), Sedona, Homegrown, Other vendor/source files. (Typically processed during implementation)||>30||The category of ‘implementation’ will be applied to these files understanding that the process of receiving the files, triaging for configuration, data mapping/processing, client review, and the probability that this will be repeated once or twice. Completion will be longer than 30 days.|
|Projects: Internal/External||>30||These projects include process improvement, documentation, etc. These projects can be client, team, or cross team requests.|
These requests generally require investigation, testing, documenting, and an email exchange with the client.
These may be simple, quick turnarounds or longer exchanges internally and externally, so completion rates will vary.
|SSO Setup Support||<30||The Setup SSO form is required. The form must be fully completed.|
|Pass through - engineering||>30||Requests for SFTP, Feature Requests, Bugs, etc. - any request that requires a Jira ticket.|