Which Components Cause Poor Performance?

I covered forms in a separate article, because that is where the "felt slowness" sits. The measured slowness of an environment, meaning sluggish saves, stalling imports and tough lists, has other causes. A ranking by potential for damage.

First place: synchronous plug-ins in the save pipeline

A synchronous plug-in that listens to Create or Update runs in the middle of the transaction. The user waits after the click until the plug-in has finished, and a data import waits for it on every single record. Two or three such steps in a row, possibly with their own data access (or a call to a web service inside), and a save turns into seconds, an import into hours.

The evidence comes from the export: the registrations with message, stage and execution mode. The question to ask of every synchronous step is whether the result really has to be available immediately within the same transaction. Surprisingly often the honest answer is "no", and by switching to asynchronous behavior the user would be rid of the wait.

Second place: registrations on retrieve messages

Plug-ins on RetrieveMultiple of the large tables run along with every list view, every search and every subgrid. A single such plug-in can make an entire environment feel sluggish, because it runs in a hundred places at once. Such registrations are rare, but when they are there, they belong at the very top of the list.

Third place: automation chains

A workflow updates a record, and that triggers the next process, which in turn writes. Individually, every step is harmless. As a chain they create load peaks and occasionally loops that only the platform's protection stops. In the solution export they become visible through the triggers: if several processes react to the same table on the same fields and write back themselves, a chain is at least possible, if not likely.

Fourth place: auditing everything

Auditing is a small thing per field and quite sensible. Enabled across the board, on every table and every field, it records every change and lets the audit table grow to sizes that weigh on storage costs and maintenance. The setting is in the export per table and per field and can be evaluated. What was usually meant: audit the 10 most important fields. What was configured: all of them.

Fifth place: rollup fields in numbers

Rollup fields are recalculated through system jobs, by default every hour. A few of them are unproblematic. Dozens on large tables create a constant background load, and their values are still never fully up to date, which regularly leads to support questions.

The point of view

What stands out about this list: none of it is an exotic error. These are normal tools in too large a dose or in the wrong place. That is why the check also works as a quantity survey from the export, entirely without runtime measurement: number of synchronous steps, retrieve registrations, trigger overlaps, audit ratio, rollup inventory. Which of these designs can already be recognized before go-live is described in detecting performance risks early. Where the numbers stand out, measuring is worthwhile. Where they do not, you can usually save yourself the measurement.