registration open

Join us for the Elsevier Conference in San Diego from April 14–16

Learn more

How Can We Help?

Search icon

Search Results

How to File a Technical Ticket

Project Managers (PM), Implementation Specialists (IS), Customer Success Managers (CSM), and Software Administrators (SA) frequently need to file technical tickets during the course of implementation. The following guide outlines the necessary information tickets should contain in order to minimize back and forth and speed throughout. The information provided here is intended to ensure efficiency and provide transparency.

 

Submit Client Community Ticket

  1. Sign into the Client Community Portal and click the Submit a Case button in the upper right-hand corner.
    Client Community Submit a Case page
  2. The ‘Submit a Case’ form will display. Fill out the form as detailed below.

Required Ticket Information

  • Required Fields: Product
  • Highly Recommended Fields: Type, Subject, Description, Product, Product Area, and Product Component (Integrations/Data Transfer)
  • Default Values: The following default values on the form are typically correct and do not need to be adjusted.
    • Type: Support/Question
    • Status: New
    • Priority: Medium
 

Salesforce Statuses

  • New: New ticket that has yet to be assigned to a consultant or engineer. This is the default status selected.
  • Open: We haven't started, or we're working on it. Check the Target Date for a sense of, well, target completion.
  • Pending on Customer: Services has either completed the task or is waiting for customer input. Automated notifications are sent to the customer from this status.
  • Closed: The ticket is complete or closed due to nonresponse. It can be reopened at any time. Closed tickets will reopen at any time if a customer responds. 
 

Specific Ticket Types

Manage UIDs

Services can run an ‘artisan command’ to assign UIDs for faculty who already exist in Faculty Search (FS), Review, Promotion & Tenure (RPT), or Faculty Activity Reporting (FAR) but were created before UIDs were introduced. This covers legacy instances created before UID.

  • Required Ticket Information: Include a CSV file formatted with two columns and these exact headers, per this template: pid and institution_user_id

If UIDs are not provisioned correctly, or an existing user is associated with the wrong UID, avoid requesting a bulk correction. Instead, submit a ticket asking Services to delete the incorrect UIDs. Once removed, you can restart the UID assignment process cleanly.

 

Double and triple-check that leading zeroes remain intact.

 
 
 

Bulk Actions

Services can perform the following bulk actions:

  • Bulk User Merges: The best use case for this is when an institution has accidentally created a lot of junk users and the ‘bad’ accounts are easily identifiable/have a common characteristic.
  • Bulk Update Emails, SSO IDs: Email addresses & SSO IDs can be updated in bulk for specific use cases such as institutional mergers or domain changes (Dixie → Utah Tech, for instance). Download the following template & return to Services (be sure to include PID).
 
 

Required Ticket Information (FAR)

Requests to load activity data, profile data, or attachments for the first time.

Prerequisites

Ideally, institutions will have their own SFTP setup. Services can set up IDM without a unique SFTP, but between setup and delivery of the first load, institutions should complete the SFTP setup form.

 

Default Scholarship or Grant Data

Once set up the first time, Services provides a default load schedule of the 1st, 10th, 20th, and 30th of the month and loads are automated. Logs are available on the SFTP.

 

Ticket Requirements (in addition to prerequisites):

  • Data file that follows the data model
  • Data file that follows the file type and naming conventions
  • Subject: “IDM [grants/scholarship] setup for [DBID]”
  • Description:
    1. What schedule would the institution like to load this file on? Would they like a custom cadence, or does the default cadence work? (1st, 10th, 20th, 30th) 
    2. If the file is not an upsert (update existing data & adding new data), indicate that.
    3. Should the records be locked when loaded? Yes/No 
    4. Who should receive email notifications about file loads? firstname.lastname@institution.edu 
    5. Ensure the contact name on the ticket is filled in with someone from the institution's project team.

Custom Sections

All custom sections are eligible for autoload via IDM if they are recurring loads (>1or 2x loads). 

 

Ticket Requirements (in addition to prerequisites):

  • Subject: “Custom [Activity/Profile] section setup for [DBID]”
  • Body:
    1. What schedule would the customer like to load this file on? 
      1. Default cadence (1st, 5th, 10th, 15th, 25th, 30th)
      2. Custom cadence (Weekly: engineer usually will pick 10th, 20th, 30th; Monthly, Quarterly, Semesterly, Yearly: customer preference custom date)
    2. What type of load would the customer like to apply for this file?
      • Upsert (update existing data): Look for updates for existing data + add new records.
      • Append/Insert (all new records): Add new records only.
    3. Should the records be locked when loaded? Yes/No 
    4. Who should receive email notifications about file loads? firstname.lastname@institution.edu 
    5. Ensure the contact name on the ticket is filled in with someone from the institution's project team.

Per the new data migration process, wherever possible, please batch tickets in groups. Batching ~3 files per helps TS engineers chunk work in roughly equal sizes but is not strictly necessary; maintaining the distinction between types of files (custom vs degree vs attachment) is more important.

 

All other data types

All other data types are currently manual (PHP) loads performed by the Services team which require scripting code. As such, for any recurring load (non-data-migration), the capacity to set up recurring cadences is limited to certain days depending on bandwidth. As with scholarship & grants data, logs are available on the SFTP and will not be emailed directly to institution beyond implementation.

 

Ticket Requirements (in addition to prerequisites):

  • Subject: “Default [Activity/Profile] section setup for [DBID]”
  • Description: Can leave blank unless you have pertinent added context.

Data types not currently available for autoload are:

  • Degrees
  • Other default sections such as Advising, Service
  • Attachments
 
 
 

Requests to reload activity data, profile data, or attachments for an institution when the data has already previously been loaded.

Activity Data, Profile Data, or Attachments (data has already previously been loaded)

Since scholarship and grants data is set up to be automated via IDM, no reloads should be requested for these data types - once a schedule is set, files will be picked up from the SFTP.

 

Prerequisites

Ideally, institutions will have their own SFTP setup. Services can script for institutions without a unique SFTP, but between setup and delivery of the first load, institutions should complete SFTP setup form if at all possible

 

Ticket Requirements (in addition to prerequisites):

  • Subject: “Reload of [Custom/Default] [Activity/Profile] section reload for [DBID]”
  • Description: Can leave blank unless you have pertinent added context.
  • Type = Data Load (optional)

For autoloaded data types, there should be no reason to submit a ticket. If an institution needs to inquire about their cadence or who is set to be notified, the Ticket Type = Support/Question

 
 
 

Required Ticket Information (FS/RPT)

Update “Email” or “SSO ID” for existing users

The institution is changing their email services or domain or their SSO IDP and needs to update users in Interfolio to change their email address or SSO ID.

 

Prerequisites

Send the institution the user list report with new columns “new_email” or “new_sso_id” for them to fill out for each user.

 

Ticket Requirements (in addition to prerequisites):

  • Tenant ID/Database ID
  • User list report with columns:
    • PID
    • new_email
    • new_sso_id
 
 

Custom Email Domain

Configure Custom Email Domain in RPT

Institutions using Review, Promotion & Tenure (RPT) may want system‑generated emails to come from their own domain rather than the default Interfolio sender (no‑reply@interfolio.com). RPT supports custom email domains, allowing messages to be sent from an address such as interfolio@institution.edu.

Because this feature has no front‑end controls, configuration must be completed by Technical Services. Use the steps below to ensure a smooth setup.

 

Custom domain support is currently available in RPT. Similar functionality for Faculty Search (FS) is on the development roadmap.

 

To avoid delays, the ticket must contain:

  • Point of contact email(s)
  • Tenant ID
  • Email address to be used for notifications
  • Confirmation that DKIM or SPF records have been configured
 
 
 

Work Owned by Other Teams (Submitted Through Services)

Services cannot directly complete the actions listed below, but you can request them through Services. These items require involvement from Engineering, DataOps, or other specialized teams, which may result in longer fulfillment timelines.

  • FAR term configuration changes
  • Add new degrees to a FAR database
  • Add CIP codes to FAR
  • Tenant deletion
  • Troubleshoot Interfolio Data Service (IDS) data loads
  • Remove SSO from a tenant (Engineering-owned)
  • FAR custom reporting (DataOps-owned)
 
Was this article helpful?
Give feedback about this article

Related Articles