Khoros Iris Web Application Development

What it is: Iris is a single, modern web application that unifies two previously separate Khoros products — Care (the agent console / ic-backend-ui) and Marketing/Publishing (publisher-ui / sf-webapp) — into one workspace, running on top of the existing legacy data layer rather than a new one. The repo description says it plainly: "Unified Khoros iris Web Application — Consolidating ic-backend-ui and publisher-ui with Modern Theme."

The problem: Khoros customers who bought both Care and Marketing were operating two aging apps with different UIs, logins, navigation, and mental models — but the same customers, the same social accounts, and often the same teams. The legacy stacks (Java ic-backend, sf-webapp) are expensive to maintain and hard to evolve. A rip-and-replace rewrite would mean a data migration across live enterprise tenants — the single riskiest thing you can do to a SaaS customer.

Why I built it this way — the strategic bet: iris is a strangler-fig rebuild, not a migration. iris-api mirrors legacy behavior on the same shared database. That single architectural decision is the product strategy:

Zero-migration adoption. A tenant can move to iris without moving their data. Cases, posts, tags, ACLs, users all stay in place; iris reads and writes the same tables legacy does.

Reversible rollout. Because both apps point at one DB, customers can run iris and legacy side by side and fall back instantly. That de-risks the sale and the migration.

Parity as the contract. The product's north star is "behave exactly like legacy, but unified and modern." Every feature is measured against legacy parity — which is why the eng work is full of "does this count match CaseRepository?" checks.

The "why" in one line: consolidate two products and modernize the UX without asking a single enterprise customer to risk their data.

2. Why I chose the features I chose?

The feature set isn't greenfield brainstorming — it's the union of the two legacy products' proven, in-use surface area, reprioritized for the unified workflow. Concretely, iris ships:

Care (agent + supervisor): conversations / agent console, case management, queues & work-queues, snooze, tags, teams, agent-assist, supervisor dashboards, Manage View (Explore-style cross-conversation view), response approval, surveys, KB.

Marketing (publisher + analytics): scheduled posts, the publisher, campaigns, per-network publishers (Facebook, Instagram, X, TikTok, YouTube, Apple Messages, Brand Messenger), publishing analytics, DAM/assets, automations.

Shared platform: enterprise auth (SAML, OIDC, LDAP, OAuth, MFA), CRM integration, network/account provisioning, analytics, audit.

The selection logic, as a PM:

Parity-first, not novelty-first. For a consolidation play, the riskiest thing isn't a missing delighter — it's a missing habit. If an agent's daily count, filter, or keyboard flow differs from legacy, adoption dies. So the feature bar was "replicate what people already depend on," which is why so much effort goes into matching exact counts and filter semantics.

The unification dividend is the shared spine. One auth layer, one set of social-account connections, one user/ACL model, one tag taxonomy — shared across Care and Marketing. That's the feature you can't get from two separate apps, and it's the reason to consolidate at all.

Channel breadth is table stakes. Enterprise social is multi-network by definition; a publisher that can't do TikTok/IG/X/YouTube/Apple isn't competitive, so per-network publishers were non-negotiable.

Deliberate non-goals: No net-new Iris-only tables, no schema changes on the shared DB. Features are built on the legacy data model precisely to preserve the zero-migration, reversible-rollout promise. A feature that requires forking the data layer would break the core strategy.

3. Why it's better than the alternatives?

vs. legacy Khoros (the incumbent it replaces):

One app instead of two — unified nav, one login, shared accounts/tags/users across Care and Marketing.

Modern web stack and theme vs. aging Java/legacy UIs → faster iteration, lower maintenance cost, better performance.

Same data, so switching cost is near-zero and reversible — you get the modernization without the migration.

vs. rip-and-replace / a net-new platform:

No data migration, no "big bang" cutover, instant rollback. For enterprise tenants with millions of live cases, this is the difference between a sale that closes and one that stalls in security/risk review.

vs. competitors (Sprinklr, Sprout, Salesforce Social/Service):

Care + Marketing genuinely on one data spine, not two acquired products bolted together with a shared logo. iris's shared account/tag/user model is native, not integrated-after-the-fact.

For the existing Khoros install base — the actual near-term market — iris wins on continuity: same data, same behaviors, same integrations, better shell. A competitor forces a full migration and retraining; iris forces neither.

The honest framing: Iris's moat isn't a feature competitors can't build — it's the migration path. For enterprises already on Khoros, the cheapest, lowest-risk modernization is the one that doesn't touch their data.

4. The most delightful feature

The unified inbox-to-publish loop on one shared account graph — an agent handling an inbound customer conversation in Care and a marketer scheduling that brand's outbound posts are looking at the same connected social accounts, tags, and permissions, with no export/handoff. In legacy, those are two apps and two data silos; in iris the wall is gone.

If I had to name a single detail: the real-time, socket-driven agent console where cases route, snooze, un-snooze, and re-bucket (needs-attention, in-review, assigned-to-me) live, with counts that match legacy to the exact number. The delight is invisible: nothing surprises a veteran agent, everything is faster. For a parity product, "you didn't notice the migration" is the highest form of delight.

5. Go-to-market strategy

Motion: land-and-modernize into the installed base first, then expand.

Beachhead — existing dual-product customers. Target tenants who already own both Care and Marketing. They feel the two-app pain most and have the least migration risk (iris sits on their existing DB). This is the fastest path to reference customers.

Wedge — "modernize without migrating." The pitch to the buyer (usually a CX/ops leader + IT) is risk reduction: same data, run in parallel, roll back anytime, retire legacy on your timeline. Sell the path, not just the UI.

Rollout mechanics — parallel-run and phased cutover. Because iris and legacy share the DB, GTM can offer: pilot with a subset of agents → run side by side → expand team by team → decommission legacy. Every step is reversible, which shortens security review and procurement.

Expansion — cross-sell the second product. A Care-only customer on iris is one toggle away from trialing Publishing on the same accounts and users, and vice versa. Consolidation isn't just a cost story; it's the built-in upsell surface.

Land price on TCO. Quantify the two-app tax (maintenance, training, integration seams) and price iris against total legacy cost, not feature count. The savings fund the switch.

Proof metrics to instrument for the pitch: agent handle-time and daily-active parity vs. legacy, time-to-first-value in the parallel run, % of teams migrated, and legacy-decommission rate (the real revenue-protecting metric).