CANDESCENT · FORGE CONTROL
Designing a Single Source of Truth for Complex Financial Institutions
Designing an organizational system that could represent hierarchy, acquisitions, branches and operational relationships—without forcing every financial institution into the same structure.
Candescent
Forge Control
Enterprise Banking
Product Design
Financial Institution
↓
Charter
Subsidiary
Branch 053
01 / CONTEXT
The problem wasn’t an org chart.
Candescent did not have a single source of truth for how a financial institution was structured. Products maintained separate organizational definitions—creating duplicated configuration, inconsistent data, synchronization problems, administrative effort and preventable configuration errors.
BEFORE
Financial Institution → Product A → Org model → Product B → Org model → Product C → Org model
AFTER
Financial Institution → Organization Service → Candescent Products
02 / INSIGHT
Organizations aren’t always trees.
The starting mental model—a clean parent-child hierarchy—breaks down fast. A regional bank may include a charter and a branch, but also acquired businesses, compliance, mortgage approval and back-office operations that do not fit one rigid structure.
Big Regional Bank → Lakeshore Charter → Branch 053
Big Regional Bank → Primary business · Acquired business · Compliance · Mortgage Approval · Back-office operations
The system needed to support hierarchy without assuming everything was hierarchical.
How do you design a system flexible enough for reality, without making the interface as complicated as reality?
COMPLEXITY
Multiple organizational models and relationships.
SCALE
Up to 1,000+ organizations, 100 subsidiaries and 10,000 branches.
CHANGE
Acquisitions, restructuring, new departments and evolving relationships.
04 / PRINCIPLES
Four principles shaped the experience
01 — Make structure visual
Administrators should understand relationships spatially rather than through forms alone.
02 — Progressive complexity
The default stays simple while supporting more complex structures when needed.
03 — Edit in context
Selecting a unit reveals its properties without taking the administrator away from the structure.
04 — Design for scale
The interaction model must work beyond a small organization chart.
03 / DOMAIN MODEL
Making the domain understandable
The conceptual model made a complex business domain legible without flattening it.
Organization ↓ Organization Unit ↓ Structure ↓ Relationships
Organization = the financial institution. Organization Unit = Bank, Charter, Subsidiary, Branch or Department. Structure = how units relate. Relationships = operational and product context.
05 / THE SOLUTION
From org chart to organizational system
The experience combines a visual structure editor with contextual details and search/navigation—so an administrator can explore, select, inspect and modify without losing context.
EXPLORE → SELECT → INSPECT → MODIFY
Structure and detail, in one place.
01 Explore the organizational structure. 02 Select a unit to understand its properties and relationships. 03 Modify the structure without leaving the context.
Why not just use a conventional tree?
CONVENTIONAL TREE — Good for predictable hierarchies, deep navigation and linear relationships. But it assumes everything has one parent.
VISUAL STRUCTURE EDITOR — Supports multiple hierarchies, disconnected structures, acquisitions, spatial relationships and future relationship types.
The canvas wasn’t chosen because it looked modern. It was chosen because the domain wasn’t strictly linear.
Designed for 20 units. Built for 10,000.
At enterprise scale, one view cannot answer every question. Use three complementary lenses.
Organizations change. The model has to change with them.
Big Regional Bank → Existing Business + Acquired Business. Acquired businesses may remain independent for an extended period, so the model supports multiple independent hierarchies, restructuring, moving units and evolving relationships—with clear confirmation when configuration may be affected.
STRUCTURE VIEW
Understand relationships
SEARCH / DIRECTORY
Find a specific unit
DETAIL VIEW
Inspect and edit properties
One abstraction. Many realities.
Organization Unit → Bank · Charter · Subsidiary · Holding Company · Branch · Department. One consistent interaction model keeps the system extensible as the institution evolves.
The organization became more than a directory.
Mortgage application → Branch 053 → Lakeshore Charter → Mortgage Approval Department. The Organization service becomes connective tissue between Candescent products and the institutions they serve.
Start with the foundation. Build toward a platform.
A phased model turns a foundational service into shared product infrastructure.
From duplicated configuration to shared organizational context.
The immediate value: a common FI structure that every Candescent product could reference.
What this project changed in how I design.
01 Reality doesn’t always fit the UI metaphor. 02 Enterprise UX is often about relationships, not screens. 03 Scale changes interaction design.
MVP
Create · Edit · Structure · Access · Search
NEXT
Branches · Departments · Bulk operations · Metadata
PLATFORM
Product enablement · Workflow routing · Shared context
ORGANIZATION UNIT
Bank
Charter
Subsidiary
Holding Company
Branch
Department
↓ REDUCE
Administrative duplication · Configuration errors · Product-specific R&D · Onboarding effort
↑ ENABLE
Consistency across products · Scalability · Shared organizational context
Designing for reality, not the org chart.
Organizations evolve. They acquire companies, open branches, create departments and restructure. A good enterprise system shouldn’t ask organizations to become simpler so software can understand them. It should give software enough structure to understand the complexity—and give people enough simplicity to manage it.