Genesys CIC-101-01: CIC Core and PureConnect

The Genesys CIC-101-01 exam is associated with CIC Core for the PureConnect Customer Interaction Center platform. The exam belongs to the on-premises PureConnect era and focuses on the core architecture and administration concepts that supported telephony, users, workgroups, routing, handlers, IVR, recording, supervision, and contact-center operations.

PureConnect is no longer a current Genesys platform. Genesys announced end of life for PureConnect, with end of support for the remaining supported releases reached on July 31, 2025. Genesys training also removed PureConnect course and certification content from its Beyond catalog in October 2024. That makes CIC-101-01 historical product knowledge rather than a current certification target, but the exam remains useful for administrators supporting archived environments or professionals migrating from CIC concepts into Genesys Cloud.

The Genesys certification portfolio now centers on Genesys Cloud and newer customer-experience capabilities. The Unit 10 Genesys Cloud AI, Digital Bots, and Knowledge article provides a modern contrast: one path represents the established on-premises CIC architecture, while the other reflects cloud-native digital self-service and AI.

CIC architecture should be understood as a collection of cooperating services

PureConnect Customer Interaction Center was built as a service-oriented contact-center platform in which telephony, routing, interaction processing, administration, recording, reporting, and client applications depended on several cooperating subsystems. Administrators needed to know which service owned a particular function before troubleshooting it.

A contact-center symptom such as calls not routing, agents not receiving alerts, prompts not playing, or recordings missing can originate from telephony, configuration, routing, handler logic, media, licensing, or a dependent service. Understanding the architecture prevents every incident from being treated as a generic server problem.

Create a component map that shows CIC server roles, telephony connections, database or reporting dependencies, media resources, client applications, and administrative tools. The map becomes the foundation for both exam study and support work.

Interaction Administrator is the central configuration model

Interaction Administrator was one of the primary tools for configuring users, workgroups, roles, lines, stations, skills, queues, schedules, security, and other platform objects. Effective administration required understanding how those objects relate rather than memorizing where a setting appears.

Workgroups are particularly important because they can define routing, queue behavior, membership, skills, activation, and operational reporting. A user can exist correctly in the directory yet fail to receive work because the workgroup, activation, skill, or routing condition is wrong.

Study configuration by following an interaction from external line to queue to agent. Identify which administrator objects influence each transition and what evidence confirms the object is being applied.

Users, stations, and workgroups represent different parts of the agent model

A user represents the person and their permissions or contact-center attributes. A station represents the endpoint or place where interactions are handled. Workgroups represent collections of users and routing or queue behavior. Treating these as interchangeable can create confusing troubleshooting.

An agent may be logged in but not available, associated with the wrong station, inactive in a workgroup, or lacking the skill needed for one queue. Each state can produce a similar complaint that the agent is not receiving interactions.

Use scenarios that change only one variable at a time: workgroup activation, station association, user status, skill value, or queue membership. This helps reveal which object controls the observed result.

Telephony and SIP configuration should be separated from routing logic

PureConnect environments could connect to carriers, gateways, PBXs, SIP infrastructure, and endpoints. A call must reach CIC successfully before workgroup routing or handler logic can operate on it.

When inbound calls fail, verify signaling and media before changing ACD rules. When outbound calls fail, check line configuration, dialing rules, route selection, carrier behavior, and media path separately.

Contact-center platforms sit at the intersection of voice protocols and application logic. The administrator should be comfortable determining whether the failure is telephony transport, CIC configuration, or routing after the call has already entered the platform.

ACD and skills-based routing should express business priority

Automatic call distribution is not simply round-robin delivery. Routing can consider workgroups, agent availability, skills, proficiency, queue time, priority, and other business rules. The design should reflect the reason one interaction belongs with one set of agents.

Skill-based routing can improve service when agents have different language, product, regulatory, or technical capabilities. Poorly designed skills can also make interactions wait unnecessarily when the rule is too restrictive.

Study the balance between specialization and capacity. A perfect skill match is not useful if no qualified agent is ever available and the business would prefer escalation or broader routing after a delay.

Handlers and Interaction Designer expose the programmable interaction workflow

PureConnect handlers allowed designers to implement or extend interaction logic through Interaction Designer. Handlers could control routing, prompts, data lookup, integration, decisions, and custom behavior around calls and other interaction types.

Handler troubleshooting should start with the trigger and execution path. Determine whether the handler started, which variables were populated, which step failed, and whether an external dependency such as a database or web service returned the expected result.

Custom logic increases flexibility and support complexity. Document why a customization exists and what standard platform behavior it replaces or extends so future maintainers can diagnose it without reverse-engineering every branch.

IVR and prompt design should reduce caller effort while preserving escape paths

Interactive voice response can collect information, authenticate callers, provide self-service, and route interactions. A technically correct menu can still create poor customer experience when prompts are long, choices are unclear, or callers cannot reach a person when self-service fails.

Design prompts around the information callers need at that moment. Keep menu depth reasonable, handle invalid or missing input, and define timeouts and retry behavior. Self-service should reduce effort rather than trap the customer.

Test IVR with real call flows and unexpected input. A caller who says nothing, enters invalid digits, disconnects, or requests an agent should still follow a predictable path.

Recording, quality, and supervision depend on both configuration and policy

Contact centers often record interactions for quality, compliance, training, or dispute resolution. Administrators need to understand which interactions are recorded, where recordings are stored, who can access them, and how retention or privacy requirements apply.

Interaction Supervisor and related monitoring tools help operations teams see queue conditions, agent status, service levels, and performance. Those metrics are useful only when workgroups, schedules, and interaction classifications are configured consistently.

Do not treat recording and supervision as purely technical features. They affect privacy, employee monitoring, compliance, and customer expectations, so policy ownership should be clear.

Reporting should connect operational metrics to customer outcomes

Contact-center reporting can include offered interactions, answered interactions, abandon rates, queue time, handle time, service level, agent state, and workgroup performance. Managers need to understand what each metric actually measures and what behavior it can encourage.

Average handle time can fall while repeat contacts rise. A high service level can coexist with poor quality if interactions are rushed. Metrics should be interpreted together and connected to customer outcome rather than optimized in isolation.

Configuration changes can alter metric meaning. If workgroup definitions or routing logic change, historical comparisons may need context so trends are not misread.

Troubleshooting should follow the interaction through each subsystem

Start with a specific interaction and timestamp. Verify carrier or line arrival, CIC recognition, handler or routing path, queue state, agent eligibility, alerting, media, completion, and recording or reporting as needed.

Preserve logs before restarting services or clearing state. A restart may restore operation but destroy the evidence needed to find the recurring cause.

Build support runbooks around common symptoms such as no inbound calls, one workgroup not routing, one agent not receiving interactions, prompt failures, media issues, recording gaps, and report inconsistencies. Each should identify the most relevant evidence first.

PureConnect end of support changes the correct operational strategy

Genesys PureConnect reached end of support in July 2025, and the vendor removed standard PureConnect training and certification content earlier. Organizations that still operate CIC should therefore treat platform knowledge as lifecycle and migration knowledge as well as day-to-day administration.

Document dependencies, custom handlers, integrations, routing rules, telephony contracts, recording requirements, reports, and user workflows before migration. The most difficult parts of a legacy contact-center move are often custom business processes rather than base telephony.

Security and operating-system dependencies also deserve special attention because an unsupported platform cannot rely on the same future patches, certification testing, or vendor support model as an active platform.

Migration to Genesys Cloud should preserve business intent, not reproduce old screens

Genesys Cloud uses a different cloud-native architecture and administration model. A successful migration should begin by identifying the intent behind PureConnect workgroups, handlers, IVR, skills, reports, integrations, and recordings rather than attempting a one-for-one screen conversion.

Some old custom logic may no longer be necessary because cloud services provide newer capabilities. Other workflows may need redesign because the business process has changed since the original CIC deployment.

Create acceptance criteria around customer journey, routing outcome, agent experience, compliance, reporting, and integration rather than around identical configuration terminology.

Use CIC-101-01 as a historical architecture map for PureConnect environments

CIC-101-01 is not a current Genesys certification path, but its concepts remain valuable when maintaining old PureConnect documentation, investigating archived configurations, or planning migration.

Focus on architecture, Interaction Administrator, users, workgroups, telephony, ACD, skills, handlers, IVR, recording, supervision, reporting, and troubleshooting. Those topics explain how the platform delivered contact-center behavior.

A strong capstone traces one inbound customer call from carrier connection through IVR, routing, agent alert, recording, completion, and reporting, then maps each business requirement to its Genesys Cloud equivalent or redesign decision.