Best practices for performance
We developed TOPdesk with very little limitations on the amount of data that can be requested or changed. However, a few functionalities used without caution can have an impact on the overall performance of your environment.
Below you can read about some best practices we recommend for the most optimal usage of TOPdesk.
Note
It may not always be possible for you to apply those tips if the data you are retrieving is essential for your process. We have accounted for these use cases, therefore to some extent each TOPdesk instance has extra room for momentary heavy use.
General tip
We recommend using the minimum amount of data that is required, because requesting or editing large amount of data has an impact on your environment's performance. For example, consider if requesting all incidents ever created has value for you if only a few have been modified since the last request was created.
API handling
Use dedicated API accounts:
Give a specific and human readable name to your automation and API accounts. This practice helps your own administration by identifying the function of each account, while also aiding TOPdesk support in investigating the logs more efficiently if needed. For example, ODATA-API, ASSET-ACTION-API, INCIDENT-ACTION-API, MAILIMPORT.
Avoid API spamming:
Make sure that in cases where external systems send API calls to TOPdesk, they don't spam the system. For example, when a server has only 5% disk space available, it automatically sends an API call to TOPdesk to create an incident. In this case make sure only one API call is sent, and avoid the same API call being sent every 5 seconds.
OData
Configure OData requests in the most optimal way. See knowledge item KI 12820 on My TOPdesk for more information.
Request the same data only once.
Only request data that has changed since the last request, or data that is relevant.
Exporting overviews to CSV
Limit the amount of exported cards.
Note
The export limit is over 1 million. (The 10,000 record overview maximum doesn't apply to exports.)
We recommend to export without memo fields, and preferably outside of working hours in case of huge volumes.
Selections
Try to use indexed values.
Tip
Dates and drop-down values are most likely indexed in the database, while memo and text fields aren't.
Avoid using too complicated selections with many sub-conditions.
For example, incidents with category X, or created after 1st January 2024 with operator group Y would be good selections. However, heavy selection examples include incidents with a memo field containing a regular word, like "error" or "printer".
Reports
Use a practical filter or selection to limit the amount of data that needs to be checked for the report.
Use a date limit.
Avoid a large amount of grouping. An example for heavy grouping is based on incidents last year grouped by day, while a good example is grouping the same by month.
Avoid adding heavy reports to the TOPdesk dashboard. This way the report is only calculated when needed, while reports on the dashboard are calculated periodically.
Mail imports
Avoid mail loops:
Follow the recommendations from knowledge item KI 10145 on My TOPdesk.
Avoid sending automatic emails to a mail import address.
Avoid or carefully consider sending automatic emails upon receiving an update via email, since the reply will be imported to TOPdesk, and a new update is also sent. This becomes a problem when the recipient has the same strategy, for example, in the case of out of office emails.
Avoid out of office messages without the original subject, because TOPdesk will interpret them as new cards and a confirmation message is likely sent out in response.
Events
Avoid event loops:
Take extra caution to properly configure the events linked to your automatic actions. (Even if TOPdesk has a mechanism to detect and prevent this kind of events.)
For example, avoid cases where you set up an automation to make changes to a card and also to receive automatic notifications when a change is made. You can do that by setting to execute an action after editing a card unless the changer of the card is the action API operator. The incident is just an example, this can happen with other card types too.
Incidents
Avoid extremely large incidents containing over 200 memo fields, because such incidents slow down your environment's performance.