[object Object]

Employee Center Pro looks good on a demo because the demo data is clean. Your demo data is not your production data. The first 90 days after rollout are when every dirty corner of your knowledge base, your topic taxonomy, and your permission model gets dragged into the light, and the executive sponsor who approved the rollout starts asking why the experience feels worse than the old portal.

The taxonomy collision you will not see in UAT

Employee Center Pro routes users into experiences through topics and subtopics. Topics are referenced from knowledge articles, catalog items, journey blueprints, and the search index. The collision: most organizations have parallel taxonomies — one for knowledge, one for the catalog, one for HR cases — and Employee Center Pro flattens them into a single navigation surface where the inconsistencies are suddenly visible.

You will discover, post-launch, that “Onboarding” is a knowledge category, “New Hire” is a catalog topic, “Joiner-Mover-Leaver” is an HR case category, and your users cannot find any of them because none of them are tagged the way Employee Center expects.

The fix is taxonomy reconciliation before rollout, not after. Pick one canonical topic tree. Map every existing knowledge category, catalog topic, and case category to a node. Anything that does not fit becomes a renaming task or a deletion candidate.

The mapping table

Table: u_ec_topic_reconciliation
  u_canonical_topic        (Reference to topic)
  u_source_table           (String: kb_knowledge, sc_cat_item, hr_case, etc.)
  u_source_category        (String)
  u_source_sys_id          (Reference)
  u_mapped_by              (Reference to user)
  u_mapped_on              (Datetime)
  u_review_status          (Choice: pending, approved, rejected)

This table is dull. The work it represents is not. Expect 4 to 8 weeks of content owner conversations to converge on a tree that everyone will accept. Skip this and the launch will be measured by how many tickets contain the phrase “I cannot find.”

Permissions are not what they appear to be

The portal-era permission model — read access through criteria records on knowledge bases and catalog categories — still applies under Employee Center Pro, but is layered with experience-level and topic-level visibility controls. The layers compose in ways that are easy to misread.

A working mental model:

  1. Experience visibility determines whether the user sees the experience at all.
  2. Topic visibility filters which topics appear in navigation within that experience.
  3. Content-level criteria still apply to individual articles, items, and cases.

A user can have permission to the experience, see a topic in navigation, and click through to a content listing that is mysteriously empty because the underlying criteria denied every article. This is functionally indistinguishable from a broken page. Diagnosing it requires you to check all three layers; junior admins will skip the third and report it as a bug.

A permission-debug script

// Background script — diagnose why a user sees nothing under a topic
var userSysId = '...';
var topicSysId = '...';

var topic = new GlideRecord('topic');
topic.get(topicSysId);
gs.info('Topic: ' + topic.name + ', active=' + topic.active);

var topicGroup = new GlideRecord('m2m_topic_taxonomy');
topicGroup.addQuery('topic', topicSysId);
topicGroup.query();
gs.info('Taxonomy memberships: ' + topicGroup.getRowCount());

var kb = new GlideRecord('kb_knowledge');
kb.addQuery('topic', topicSysId);
kb.addQuery('workflow_state', 'published');
kb.query();
var total = kb.getRowCount();
var visible = 0;
while (kb.next()) {
    var can = sn_kmf.KnowledgeHelper.canReadArticle(kb.sys_id.toString(), userSysId);
    if (can) visible++;
}
gs.info('Articles under topic: total=' + total + ', visible_to_user=' + visible);

Run this against any “I see nothing” report. Usually one of three things: the topic is inactive, the article criteria are misaligned with the user’s groups, or the user is not a member of the experience audience. The script tells you which one in 5 seconds.

Content ownership is the rollout’s real long pole

Every topic needs an owner. Not a vague team mailing list — a named person who is on the hook for content freshness, accuracy, and retirement. Without named ownership, content rots, the topic accumulates stale articles, and search relevance degrades within a quarter.

The discipline is structural:

  • Every topic record has an owned_by field, required, no default.
  • A monthly report lists topics whose newest published article is older than 180 days, grouped by owner. Send it to the owners and their manager.
  • A topic with no published content for 365 days is auto-flagged for retirement. The owner has 30 days to retire it or republish.

This sounds bureaucratic. The alternative is content rot, which is invisible until it is catastrophic.

Search relevance: the silent killer

Employee Center Pro relies on Zing-era search, with newer relevance features layered on. If your knowledge base has not been groomed for search — meaningful titles, populated metadata, sane keyword tagging — the rollout will surface that and your users will conclude “the new portal cannot find anything.”

The pre-rollout grooming pass:

  1. Identify articles with titles shorter than 6 words. Most need rewriting.
  2. Identify articles whose title is a question and whose body does not answer it directly. Rewrite the lead.
  3. Identify articles tagged with no topic or with a deprecated topic. Re-tag.
  4. Identify articles last updated more than 18 months ago in a category that changes faster than that (HR policy, security guidance, expense). Schedule for review.

You will not finish this pass before the rollout. Do as much as you can, and accept the rest as the first quarter’s content roadmap.

For the related discipline on the catalog side, see our piece on knowledge management taxonomy rebuilds.

Journeys: the feature you should use sparingly

Employee Center Pro’s journey blueprints (onboarding, role change, leave) are powerful and over-engineered for most organizations. The trap is building a 47-step journey for new hire onboarding, watching nobody complete it, and discovering that the bottleneck was a 90-day-out task that everyone forgot existed.

Two patterns work better:

  • Short journeys: 5 to 10 steps, covering the first 30 days only. Anything beyond goes into a follow-on journey triggered at day 31.
  • Owner-anchored journeys: each step has a named owner who is paged if the step ages past its SLA, not a generic group queue.

Long journeys without anchored ownership produce the same dead-letter problem at scale: tasks pile up, nobody is accountable, the executive dashboard shows yellow and red squares nobody knows how to clear.

UI density and what to keep off the homepage

The default Employee Center Pro homepage tries to show everything: featured items, journeys in progress, knowledge promotions, case status, a Now Assist chat surface, and an announcement banner. On a 13-inch laptop screen this is too much.

Prune ruthlessly. The right homepage for most populations:

  • A search bar, prominent, with a placeholder hint
  • Currently open cases and requests, max 5
  • Featured items section, max 4
  • A single announcement slot

Anything else lives one click deep. The portal-era instinct of “more is more” is wrong here; the goal is task completion, not surface area.

The cutover window

Run Employee Center Pro and the legacy portal side by side for at least one quarter. The cutover discipline:

  1. Internal launch first: a controlled audience (IT, HR, a friendly business unit) for 2 weeks.
  2. Phased rollout to remaining audiences over 4 to 6 weeks.
  3. Legacy portal stays available, with a banner pointing to the new experience, for another 4 weeks after full rollout.
  4. Legacy portal redirects, then sunsets, only after a full month of stable adoption metrics.

A faster timeline is possible. It is also how rollouts get rolled back.

Listening posts after launch

The first 30 days post-launch are when most of the learnable signal arrives. Set up listening posts before launch, not after:

  • A feedback channel inside Employee Center itself (a “How is this working for you?” widget on every page)
  • A weekly aggregation of help-desk tickets containing keywords like “cannot find,” “broken,” “new portal”
  • A search-failure log that captures every query returning zero results
  • A bounce-rate report by topic so you can see which sections users abandon

The zero-result search log is the highest-value artifact. Every entry is either a content gap (write a knowledge article) or a vocabulary mismatch (add a synonym). Mining this log weekly closes the loop between user intent and content coverage faster than any quarterly content review can.

Mobile considerations

Employee Center Pro on mobile is not just the desktop view shrunk down. Forms render differently, journey UIs collapse, search behaves differently. Test deliberately on real devices, not just on a desktop browser at narrow width. The most common surprise: a catalog item form that renders fine on desktop has a multi-select field that is unusable on a phone, and the field happens to be required.

Add a mobile-specific QA pass to every catalog item launch. The work is small per item; the user pain when skipped is large.

Tradeoffs to be honest about

Employee Center Pro is a more opinionated experience than Service Portal. You get faster time-to-value for the use cases it covers well, and more friction when you want to customize beyond its model. If your portal is heavily custom — bespoke widgets, unusual layouts, deep integrations — the migration cost will exceed the benefit. Be honest about whether your customizations are differentiation or accumulated technical debt.

Bottom line

  • Reconcile your taxonomy before launch. Topic collisions across knowledge, catalog, and HR are the most common reason users cannot find anything.
  • Permissions compose in three layers. Build a debug script and pin it to your runbook before you go live.
  • Every topic needs a named owner and a freshness SLA. Without one, content rot is a quarterly disaster.
  • Journeys work better short and owner-anchored. Long, generic journeys produce dead-letter queues nobody clears.
  • Run parallel with the legacy portal for at least a quarter. The cutover that looks fast on a slide is the one that gets rolled back.
[object Object]
Share