Request Type | Explanation |
Critical Incidents |
Issues preventing you from day-to-day operations. The service is not available, records are not appearing, or a production module is not working. |
Bugs & Problems | Bugs and other unexpected behavior. A feature is working incorrectly, but is not preventing you from day-to-day operations, and/or you can find a workaround. |
Configuration Services | E.g. adding, modifying, removing: indices, facets, sorting, record fields, submission fields, email templates, collections. |
Technical Services | Assistance with cataloging templates, loan rules, right/access management, data exports and imports, batch processing, updating, or deletion of data. |
Helpdesk |
Ask questions related to use of the software. E.g. how do I make a collection restricted? How do I export a list of records? |
New Feature Requests |
Suggestions for new functionality in the TIND system. These are considered as part of product development and there are no guarantees the requested feature will be implemented. |
Depending on the request type, tickets go into a workflow where they are handled by the respective team and at the appropriate priority level.
Each request has a status associated with it. As the request moves through the associated workflow, the request status is updated continuously.
You can find a complete overview of all submitted (and shared) requests on the support request dashboard.
TIND has staff on duty 24/7 to resolve critical issues. While critical issues follow the same processing workflow as bugs, the resolution time for most critical issues is less than 24h.
TIND has sophisticated monitoring to catch downtime and other performance issues.
When a site response is less than 7 seconds, an engineer on duty will get an automated phone call alert.
We are continuously monitoring memory usage, disk space, load average and indexing tasks to address issues before they become an actual problem.
Most likely, we're on the issue and have resolved it well before you notice it. Whenever an incident occurs, we will provide you with a detailed incident report.
Bugs & problem requests are continuously monitored and assessed.
Problem assessment is usually done within a matter of days. Resolution times for workflow stages are given below.
The diagram and table below explain the workflow and what each issue status means.
The time it takes to deliver a fix for a bug report can vary based on a number of factors,
including complexity of the problem, urgency, and impact.
Assessment |
1 week |
This is the time it takes us to review and reproduce reported bugs. Problems can often be resolved during the assessment period. If it is something that can be resolved quickly, every effort is made to do so. |
Fixing |
1-4 weeks |
If the bug is considered "high priority" or is affecting many customers, it will be sent to the development team for an immediate fix. |
Dev Queue |
Up to 6 months |
More complicated or less urgent bugs are scheduled into our development roadmap in the next available cycle. |
Dev Backlog |
Based on priority | Bugs that appear to be "simple" at first glance can actually prove to be technically difficult to solve (for instance a bug related to the search algorithm). Lower impact issues that require development will require a longer time to address. |
Time frame for delivering the service depends mainly on the scope of the request and available resources.
Basic service requests requiring less than 2 hours of work should take up to 4 weeks to deliver.
Advanced service requests requiring up to 4 hours of work take between 4-8 weeks to deliver.
Service requests requiring more than 4 hours of work to complete will be scoped for time and cost.
Advanced or customization service requests requiring more than 4 hours of work will be scoped as a paid service. Solution and timeline will be agreed with customer.
Typical paid services are customizations of submission workflow, site URL, front page, authority setup, export formats, translations. New submission forms, new record types. Integrations with SSO, Discovery Service.
Questions related to the use of the software are usually answered daily when possible or within 1-2 weeks if the answer requires additional research.
More advanced questions can take more time to process, because they could require a developer to look into the code or database, or because they may require the involvement of a product manager.