Editorial illustration.
Originally published 26 June 2023; rewritten and reviewed on 15 October 2026.
A progress indicator reaches 100%, but the update still fails while saving the last record. That is a useful reminder that percentages need a defined meaning. The original Kentico example returned a fixed 50; it demonstrated a label, not a measurement.
Choose a unit of completed work
For a known batch, count records successfully processed against the total. Keep the calculation independent of the UI control:
static int CalculatePercent(long completed, long total)
{
if (total <= 0) return 0;
double value = completed * 100.0 / total;
return (int)Math.Clamp(value, 0, 100);
}
Math.Clamp requires a compatible .NET target; older projects can implement equivalent bounds checks. An unknown total should normally show an indeterminate state rather than an invented percentage.
Adapt the display to the installed Kentico version
The archived post concerned a Web Forms-era cms:AsyncControl. Its events and status APIs are version-specific. Confirm the control contract in the documentation shipped with the project before wiring the calculation to it; the original sample should not be treated as a universal current API.
Keep background work away from request-bound UI objects. Persist or expose job state through an appropriate application mechanism, and authorise access so users cannot inspect somebody else’s job.
Define success separately
Use states such as queued, running, finishing, completed, failed and cancelled where they reflect the workflow. Only mark the operation completed after its required writes have succeeded. Report a useful failure without revealing credentials or sensitive records.
Test an empty batch, a partial failure and a retry. The indicator should help someone understand what the system knows, including when the total is uncertain. An honest “finishing” state is more useful than a reassuring percentage that has stopped meaning anything.