Case study 02 · Protected
This case study is password protected.
Incorrect password. Please try again.
Rebuilding a fragile, platform-wide calculation engine to support sophisticated analytics — without breaking everything already depending on it.
Formula Builder powers iLEVEL's calculation engine — the layer responsible for portfolio metrics, benchmarking, and financial reporting. As Private Credit strategies expanded across private equity firms, clients increasingly relied on advanced analytics: weighted rollups, CAGR, quartile rankings, standard deviation calculations.
Legacy Formula Builder was not designed to handle these dynamic calculations, and extending it further would have made an already fragile system harder to maintain. Many firms relied on professional services just to manage formulas — small changes could unintentionally break downstream calculations across the platform.
Continuing to extend the legacy system would limit the platform's ability to support more sophisticated analytics at exactly the moment clients needed them most.
The need to replace legacy Formula Builder had been recognized internally for years, but scope had repeatedly delayed the effort. The project finally moved forward when a new Head of Product prioritized it as a foundational investment — particularly to support upcoming Credit and Benchmark initiatives.
Because Formula Builder touches nearly every part of the platform, the main challenge became scoping the work responsibly. My role focused on identifying where structural improvements were necessary versus where complexity needed to be deferred.
Advocated deferring a visual formula dependency map — implementing it would have significantly expanded engineering scope — in favor of simpler visibility improvements addressing the same underlying need.
Explored consolidating historically-separated data item types, but deferred the architectural change while ensuring the redesigned system could support both models in future.
Initially underestimated how closely Formula Builder should integrate with the platform's Data Trace audit system — partially addressed within scope, flagged as a follow-on priority.
Why the system was structurally messy
Formula Builder sits on top of iLEVEL's Data Item system, which had historically prioritized flexibility. Over time this created governance challenges: firms accumulated duplicate data items, inconsistent naming conventions, and overlapping configurations.
A separate initiative — Data Item Standardisation (DIS) — proposed a layered governance model. Due to scale, DIS was deferred. As a result, the redesigned Formula Builder needed to function within the existing data item model while remaining compatible with the future DIS architecture.
How formulas are resolved
A core challenge was determining how formulas should apply across entities. Legacy iLEVEL used three levels of scope — but in practice the model was both rigid and ambiguous:
| Legacy scope | Intended meaning | Problem in practice |
|---|---|---|
| All Assets | Applied across entire portfolio | Interpreted as "literal all" or "global default" — both existed in code |
| Static associations | Applied to specific entities | Little flexibility between all and specific — no middle ground |
| Dynamic entity groups | Attribute-defined groups | Overlapping scopes created conflicts with no resolution mechanism |
The redesign replaced the ambiguous "All Assets" with Default and introduced a flexible association structure. We also introduced Priority Rules — allowing administrators to explicitly define the order associations are evaluated. This shifted formula resolution from implicit behavior to an explicit, predictable rule system.
Diagram · Association model & Priority Rules
Default → Entity Group → Static Entity hierarchy, with Priority Rules resolving overlaps
Priority Rules preserved flexibility while eliminating ambiguity — admins could now reason about what would happen rather than discovering it through broken calculations.
How formulas are written
Most users expected formula creation to behave like Excel. Legacy Formula Builder did not meet that expectation. The redesigned interface adopted a more familiar formula-building experience while accommodating iLEVEL's more dynamic calculation model — formulas that operate across different entities, scenarios, and time offsets.
The redesign aimed to preserve the familiarity of spreadsheet formula entry while making these additional dimensions more visible and manageable.
Screen · Formula Builder interface
WYSIWYG editor with entity scope, time offset, and scenario selectors inline
How formulas and data items are understood and maintained
Users struggled to understand what existed in their environment. Firms accumulated large numbers of data items and formulas with slight naming variations. iLEVEL would warn an item was in use elsewhere but offered little help identifying where — so administrators avoided making changes, allowing configuration debt to accumulate.
We deferred the full visual dependency map and instead delivered simpler, higher-leverage visibility improvements:
A unified page showing all data items in the environment — a capability that didn't previously exist
Searchable tables with formula previews, letting admins quickly locate where calculations were defined
Last-used timestamps, surfacing data items likely redundant or no longer active
A drawer pattern for rapid inspection — replacing cumbersome modal dialogs
Rebuilding Formula Builder stabilized the platform's calculation engine at a time when clients were demanding more sophisticated analytics. The redesigned system supports advanced calculation types while reducing the fragility that previously required professional services to maintain formulas.
Without a stable calculation layer, clients could increasingly rely on external tools — or emerging AI-driven analytics platforms — to manage portfolio calculations outside the system. Strengthening Formula Builder ensured that calculations, data, and auditability remain anchored within iLEVEL.