Part 014 — Configuration Context, Session State, Drafts, and Recalculation

Positioning

Configuration dalam CPQ bukan hanya hasil akhir berupa list characteristic values.

Ia adalah interactive decision process.

Selama proses tersebut, user dapat memiliki state yang:

• belum lengkap;
• sementara invalid;
• stale;
• membutuhkan qualification;
• atau berubah karena context.

Jika configuration langsung dipaksa menjadi Quote Item yang selalu valid, sistem akan kesulitan mendukung:

• guided selling;
• progressive disclosure;
• collaboration;
• autosave;
• compare;
• resume;
• dan complex B2B solution design.

Core thesis: configuration session harus dimodelkan sebagai first-class lifecycle yang memisahkan working state dari committed commercial snapshot, sambil mempertahankan context, provenance, version, dan recalculation semantics.

1. What a Configuration Session Is

A Configuration Session represents a temporary or persistent workspace where actor:

• selects offering;
• enters values;
• adds components;
• receives recommendations;
• resolves constraints;
• and explores alternatives.

2. Configuration Result versus Session

Configuration Result

A valid selected product structure.

Configuration Session

The evolving process that may contain:

• incomplete;
• invalid;
• stale;
• and alternative states.

3. Why Sessions Matter

Sessions support:

• long-running deals;
• large configurations;
• collaboration;
• recovery from interruption;
• and explicit context.

4. Session Identity

A session should have stable identity.

Example:

Configuration Session ID
Tenant
Owner
Created At
Version

5. Session Lifecycle

Possible states:

Draft
-> InProgress
-> Valid
-> Stale
-> Committed
-> Expired
-> Abandoned

6. Draft

Draft allows incomplete state.

It should not imply orderability.

7. In Progress

User is actively changing selection.

8. Valid

Current configuration satisfies applicable constraints.

It may still lack price or approval.

9. Stale

Context or catalog changed after last validation.

10. Committed

Configuration has been attached or snapshotted into a quote revision.

Committed state may be immutable or versioned.

11. Expired

Session no longer active due to policy.

Historical data may still be retained.

12. Abandoned

User explicitly stops work.

13. Working State

Working state may be invalid.

Example:

• required component temporarily removed;
• value entered before prerequisite;
• partial site list uploaded.

This is normal in interactive configuration.

14. Committed State

Committed configuration should meet defined validity and completeness for target operation.

15. Session versus Quote Draft

Possible designs:

• session exists independently;
• session embedded in quote draft;
• or hybrid.

16. Independent Session

Benefits:

• reusable exploration;
• compare alternatives;
• and pre-quote guided selling.

Risks:

• extra lifecycle;
• and synchronization.

17. Embedded Session

Benefits:

• simpler ownership;
• direct quote linkage.

Risks:

• quote aggregate becomes large;
• and invalid working state mixes with commercial revision.

18. Hybrid Model

Use session for working state, then commit snapshot into quote.

Often a strong separation.

19. Configuration Context

Context may include:

• tenant;
• market;
• channel;
• actor;
• customer/account;
• sites;
• existing products;
• contract;
• effective time;
• catalog publication;
• and requested action.

20. Context Is Part of the Input

Same offering and values may produce different result under different context.

21. Tenant Context

Affects:

• catalog overlay;
• rules;
• visibility;
• and customization.

22. Market Context

Affects:

• offering availability;
• price;
• terms;
• and regulation.

23. Channel Context

Affects:

• product visibility;
• price;
• and approval.

24. Actor Context

Affects:

• permissions;
• guided options;
• and visibility.

25. Customer Context

Affects:

• eligibility;
• contract;
• segment;
• and price.

26. Account Context

May affect:

• billing;
• contract;
• credit;
• and installed portfolio.

27. Site Context

Affects:

• serviceability;
• tax;
• capacity;
• and technical options.

28. Existing Product Context

Needed for:

• modify;
• upgrade;
• dependency;
• and compatibility.

29. Effective Time Context

Determines which:

• catalog;
• price;
• rule;
• and terms

apply.

30. Requested Action Context

ADD, MODIFY, DELETE, SUSPEND, RESUME, or REPLACE can change valid options.

31. Context Snapshot

A session should record the context used for evaluation.

32. Live Context versus Snapshotted Context

Live

Always reads current source.

Snapshot

Preserves initial facts.

Use hybrid with revalidation policy.

33. Context Drift

Context changes while session remains open.

Examples:

• customer segment changed;
• catalog activated;
• inventory product modified;
• and site feasibility expired.

34. Drift Detection

Compare:

• source version;
• timestamp;
• publication;
• and dependency versions.

35. Drift Response

Possible actions:

• mark stale;
• refresh automatically;
• prompt user;
• revalidate;
• or block commit.

36. Silent Refresh Risk

Automatic refresh can:

• remove values;
• change price;
• and invalidate user decisions.

Make impact visible.

37. Session Version

Every mutation should increment version.

Supports:

• optimistic concurrency;
• autosave;
• and collaboration.

38. Optimistic Concurrency

Client submits expected version.

If stale:

• reject;
• return diff;
• or offer merge.

39. Pessimistic Lock

May be useful for short specialist edit.

Poor fit for long sessions.

40. Collaborative Editing

Multiple users may:

• edit different sections;
• review;
• and comment.

Need concurrency and ownership rules.

41. Single Writer, Multiple Readers

Simpler policy:

• one active editor;
• many viewers.

42. Section-Level Ownership

Different specialists own:

• pricing;
• technical design;
• and site data.

Can reduce conflict.

43. Merge

Merging configuration changes requires semantic merge, not only JSON merge.

44. Conflict

Examples:

• both users change same characteristic;
• one removes component another edits;
• catalog refresh conflicts with user selection.

45. Conflict Resolution

Possible:

• last writer wins;
• manual merge;
• priority by role;
• or branch.

Last-write-wins is risky.

46. Branching

A session may create alternatives.

Example:

• fiber design;
• wireless design.

47. Compare Alternatives

Comparison may include:

• structure;
• price;
• feasibility;
• lead time;
• and risk.

48. Branch Identity

Each branch needs:

• parent session;
• version;
• and provenance.

49. Merge Alternative

Combining alternatives may be unsupported or require new branch.

50. Clone

Clone creates a new independent session or branch.

Preserve source lineage.

51. Autosave

Autosave improves resilience.

Need:

• version;
• debouncing;
• error feedback;
• and offline behavior.

52. Autosave Failure

Do not show saved state if persistence failed.

53. Partial Save

Large configuration may save only changed subgraph.

Need atomicity policy.

54. Eventual Save

Client may queue changes.

Risk:

• closing browser before sync;
• conflict;
• and stale validation.

55. Offline Configuration

Possible for field sales or disconnected environments.

Requires:

• local snapshot;
• conflict resolution;
• and security.

56. Session Expiry

Expiry policy should define:

• inactivity duration;
• hard maximum;
• warning;
• retention;
• and resume.

57. Resume

Resume should restore:

• selection;
• context;
• version;
• validation state;
• and unresolved issues.

58. Resume after Catalog Change

Session may need migration or revalidation.

59. Resume after Customer Change

If customer context changed, result may no longer be valid.

60. Session Ownership

Possible owners:

• individual user;
• team;
• opportunity;
• quote;
• or account.

61. Transfer Ownership

Sales handoff may transfer session.

Need:

• authority;
• audit;
• and permission update.

62. Session Access

Control:

• view;
• edit;
• clone;
• commit;
• and abandon.

63. Tenant Isolation

Session data must be tenant-scoped in:

• storage;
• cache;
• search;
• and events.

64. Sensitive Data

Configuration may include:

• topology;
• credentials;
• and customer network data.

Apply field-level security.

65. Session Data Model

Possible sections:

• context;
• root selection;
• nodes;
• relationships;
• characteristic values;
• validation;
• qualification;
• price preview;
• and audit.

66. Root Selection

Session may begin with:

• offering;
• category;
• use case;
• or customer need.

67. Configuration Graph

Represent selected structure as:

• nodes;
• edges;
• values;
• and state.

68. Node Identity

Each selected occurrence needs stable identity.

69. Relationship Identity

Preserve source catalog relationship and configured edge identity.

70. Value Provenance

Store:

• user;
• default;
• inherited;
• calculated;
• imported;
• or migrated.

71. Issue Model

A session should retain unresolved issues:

• validation errors;
• warnings;
• missing data;
• stale dependencies;
• and manual review.

72. Validation Snapshot

Store current validation result with:

• version;
• rules;
• and time.

73. Qualification Snapshot

Store current qualification result with validity.

74. Price Preview

A session may calculate indicative price.

It is not necessarily the authoritative quoted price.

75. Price Preview Expiry

Mark preview stale when inputs or pricing context change.

76. Recalculation

Recalculation updates derived state after change.

Possible targets:

• defaults;
• constraints;
• qualification;
• price;
• and recommendations.

77. Full Recalculation

Recomputes entire configuration.

Simple but expensive.

78. Incremental Recalculation

Recomputes affected dependency subgraph.

Faster but more complex.

79. Dependency Graph

Track which outcomes depend on:

• selected value;
• context;
• and external fact.

80. Dirty Set

After change, mark affected nodes/rules as dirty.

81. Recalculation Order

Need deterministic dependency order.

Avoid incidental traversal.

82. Fixed Point

Some derived rules may need repeated evaluation until no change.

Guard against infinite loops.

83. Cycle

Rule dependencies can create cycle.

Detect at publication or runtime.

84. Recalculation Idempotency

Same state and context should yield same derived result.

85. Recalculation Side Effects

Prefer pure calculation.

External calls should be separated and cached with validity.

86. User Change versus Derived Change

Distinguish:

• user changed value;
• system default changed;
• system auto-added component;
• and migration changed value.

87. Change Set

A change set can include:

• command;
• previous value;
• new value;
• derived effects;
• and reason.

88. Undo

Undo should consider derived changes.

89. Redo

Redo may become invalid after context/catalog change.

90. Audit Trail

Record meaningful changes, not every keystroke necessarily.

91. Command Model

Examples:

• SelectOffering;
• SetCharacteristic;
• AddComponent;
• RemoveComponent;
• ApplyContext;
• RefreshCatalog;
• CommitToQuote.

92. Command Validation

Validate:

• session state;
• actor;
• version;
• and domain rules.

93. Idempotent Commands

Useful for:

• autosave retry;
• and unstable network.

94. Commit to Quote

Commit should:

• validate;
• ensure qualification policy;
• snapshot configuration;
• record catalog/rule versions;
• and create or update quote revision.

95. Commit Preconditions

Possible:

• no blocking issues;
• required context present;
• qualification current;
• price preview optional/current;
• and actor authorized.

96. Commit Idempotency

Repeated commit should not create duplicate quote items.

97. Commit Result

Return:

• quote ID;
• revision;
• quote item IDs;
• and session version.

98. Session after Commit

Options:

• immutable;
• cloned for future edit;
• remain linked;
• or closed.

99. Edit after Commit

Usually create:

• new session version;
• or new quote revision.

Do not mutate committed snapshot silently.

100. Configuration Completeness

Completeness means all required information for target transition exists.

101. Configuration Validity

Validity means constraints are satisfied.

Complete and valid are distinct.

102. Configuration Consistency

No contradictory selections or derived state.

103. Configuration Freshness

Dependencies and rules are current enough for target action.

104. Configuration Readiness

A composite result may include:

• complete;
• valid;
• qualified;
• priced;
• and commit-ready.

105. Progress Indicator

UI may show:

• sections complete;
• unresolved issues;
• and next action.

Avoid fake percentage without semantics.

106. Guided Selling

Session can guide:

• questions;
• recommended offerings;
• and next choices.

107. Questionnaire

Customer needs may be captured before offering selection.

108. Need Model

A Need Model should not be confused with configured product.

It may map to multiple offerings.

109. Recommendation Context

Recommendations depend on:

• answers;
• customer;
• market;
• and existing products.

110. Recommendation Acceptance

Selecting recommendation creates explicit product selection.

111. Large Configuration

Large enterprise deals may include:

• thousands of sites;
• repeated components;
• and bulk imports.

112. Bulk Import

Need:

• schema;
• validation;
• partial failure;
• and row-level reasons.

113. Bulk Edit

Example:

• set bandwidth for 100 sites.

Need preview and impact.

114. Template Configuration

Reusable templates can accelerate repeated setups.

Need version and ownership.

115. Template versus Session

Template is reusable definition.

Session is customer/context-specific working state.

116. Site Template

A multi-site quote may apply common template with per-site overrides.

117. Override Precedence

Example:

Global session value
< Group value
< Site-specific override

118. Bulk Recalculation

Large changes should be asynchronous if expensive.

119. Async Session Job

Possible jobs:

• import;
• deep validation;
• qualification;
• pricing;
• and optimization.

120. Job State

Track:

• submitted;
• running;
• partial;
• completed;
• failed;
• cancelled.

121. Partial Result

Allow user to inspect completed sections while job continues if safe.

122. Cancellation

Cancelling job should not corrupt session.

123. Configuration API

Possible endpoints/resources:

• sessions;
• nodes;
• values;
• validation;
• qualification;
• price preview;
• and commit.

124. Chatty API Risk

Updating one characteristic per network request can be expensive.

Use batch change set where useful.

125. Coarse API Risk

Sending entire huge session on every change causes conflict and payload cost.

126. Patch

A domain-specific patch is safer than generic JSON Patch for complex semantics.

127. Command API

Example:

{
  "command": "SetCharacteristic",
  "sessionId": "CFG-123",
  "expectedVersion": 18,
  "nodeId": "NODE-4",
  "characteristicId": "bandwidth",
  "value": 1000,
  "unit": "Mbps"
}

128. Event Model

Possible events:

• ConfigurationSessionCreated;
• CharacteristicSelected;
• ComponentAutoAdded;
• ConfigurationValidated;
• SessionMarkedStale;
• ConfigurationCommitted.

129. Event Granularity

Avoid publishing every UI keystroke externally.

Publish meaningful domain changes.

130. Persistence Model

Possible:

• relational normalized graph;
• document snapshot;
• event sourcing;
• or hybrid.

131. Document Snapshot

Good for fast load and versioned save.

Need indexing for selected fields.

132. Event Sourcing

Supports history and undo.

Adds complexity.

133. Hybrid Persistence

Store current snapshot plus change log.

Often practical.

134. Session Size

Large sessions require:

• pagination;
• partial loading;
• and subgraph APIs.

135. Cache

Cache definitions and derived results by version/context.

Do not cache user-specific session without strict keys.

136. Search

Users may need to search components/sites within session.

137. Performance Metrics

Track:

• session load;
• save latency;
• recalculation;
• validation;
• qualification;
• and commit.

138. User Experience Metrics

• abandonment;
• time to valid configuration;
• validation-error rate;
• and rework.

139. Session Observability

Support should see:

• current state;
• owner;
• version;
• catalog;
• last command;
• stale reasons;
• and active jobs.

140. Correlation

Link session to:

• opportunity;
• quote;
• customer;
• and jobs.

141. Session Incident

Examples:

• lost autosave;
• stale session committed;
• duplicate quote item;
• cross-user overwrite;
• and hidden derived change.

142. Recovery

Possible:

• restore prior version;
• replay command;
• clone session;
• and rebuild derived state.

143. Session Reconciliation

Compare:

• persisted values;
• derived result;
• catalog definition;
• and quote snapshot.

144. Session Smells

• no session identity;
• quote item mutated directly;
• all intermediate state must be valid;
• context not persisted;
• and no version/concurrency.

145. Context Smells

• tenant read from global variable;
• market inferred from locale;
• current catalog used implicitly;
• and action type absent.

146. Recalculation Smells

• full recalculation on every keystroke;
• hidden side effects;
• unstable ordering;
• and derived values overwrite user choices.

147. Collaboration Smells

• last-write-wins;
• no conflict visibility;
• and ownership stored only in UI.

148. Anti-Patterns

Quote as scratchpad

Commercial aggregate contains invalid working state.

Session as anonymous JSON

No identity, version, or lifecycle.

Silent auto-correction

User selection changes without explanation.

Context from ambient state

Same request produces non-reproducible result.

Commit by copying current tables

No snapshot or provenance.

149. Configuration Session Template

## Session Identity

## Owner and Access

## Lifecycle State

## Version

## Context

## Catalog Publication

## Selection Graph

## Characteristic Values

## Validation

## Qualification

## Price Preview

## Active Jobs

## Stale Reasons

## Audit

## Quote Link

150. Context Template

Tenant:
Market:
Channel:
Actor:
Customer:
Account:
Sites:
Existing products:
Requested action:
Effective time:
Catalog publication:
Contract:

151. Change Set Template

Command ID:
Session ID:
Expected version:
Actor:
Changes:
Derived effects:
Validation impact:
Qualification impact:
Pricing impact:
Resulting version:

152. Commit Template

Session:
Expected version:
Target quote:
Commit mode:
Validation requirement:
Qualification requirement:
Catalog/rule versions:
Idempotency key:
Result:

153. Worked Example: New Connectivity Session

Context:

• enterprise customer;
• direct channel;
• 20 sites;
• Indonesia market;
• ADD action;
• publication 21.

User selects:

• Premium Connectivity;
• 1 Gbps;
• dual access.

System:

• adds managed router;
• validates;
• qualifies sites;
• computes preview.

154. Worked Example: Temporary Invalid State

User removes base connectivity before replacing it.

Session becomes invalid temporarily.

System allows editing but blocks commit.

155. Worked Example: Context Drift

Customer contract updated while session open.

Session marked stale.

Refresh shows:

• new price;
• changed allowed term;
• and approval impact.

156. Worked Example: Collaborative Edit

Presales edits technical options.

Sales edits commercial term.

Both use optimistic versioning.

Conflicting shared field requires manual resolution.

157. Worked Example: Alternative Branches

Branch A:

• fiber access.

Branch B:

• wireless access.

Compare:

• feasibility;
• price;
• lead time;
• and risk.

Selected branch is committed.

158. Worked Example: Bulk Site Import

CSV imports 500 sites.

Result:

• 460 valid;
• 25 duplicate;
• 15 missing geocode.

Session retains partial data and issue list.

159. Worked Example: Commit Retry

Client commits session.

Response times out.

Retry with same idempotency key returns original quote revision.

160. Worked Example: Derived Value

Premium tier derives:

• monitoring = enabled.

User cannot edit derived field.

Provenance shows source rule.

161. Senior Engineer Operating Model

Treat session as lifecycle

Not anonymous temporary data.

Persist context

Avoid ambient assumptions.

Allow incomplete work

But protect commit boundary.

Use optimistic concurrency

Long sessions cannot hold locks.

Separate user and derived changes

Protect intent.

Make drift explicit

No silent refresh.

Design incremental recalculation

For scale.

Commit as idempotent transformation

Preserve versions and provenance.

162. Internal Verification Checklist

Session model

• Does configuration have its own identity?
• Is it separate from quote?
• What lifecycle states exist?
• Can invalid intermediate state be stored?

Context

• Which context fields are persisted?
• Is catalog publication pinned?
• How are customer/site/inventory versions tracked?
• How is context drift detected?

Concurrency

• Is optimistic locking used?
• Can multiple users edit?
• Are branches/alternatives supported?
• How are conflicts resolved?

Persistence

• Snapshot, event, relational, or hybrid?
• Is autosave reliable?
• Are large sessions partially loaded?
• Can sessions be restored?

Recalculation

• Full or incremental?
• Are dependencies explicit?
• Are user overrides preserved?
• Are derived changes explainable?

Commit

• What checks are required?
• Is commit idempotent?
• Does it create new quote revision?
• What happens to session afterward?

Operations

• Can support inspect stale reasons and jobs?
• Are session metrics available?
• What recovery tools exist?
• How are expired sessions retained?

163. Practical Exercises

Exercise 1 — Session lifecycle

Design states and transitions for configuration session.

Exercise 2 — Context inventory

List every context input affecting configuration.

Exercise 3 — Drift policy

Define refresh behavior for catalog, customer, inventory, and contract changes.

Exercise 4 — Concurrency

Design conflict handling for two simultaneous editors.

Exercise 5 — Incremental recalculation

Create dependency graph for five characteristics and two components.

Exercise 6 — Commit contract

Design idempotent commit-to-quote with version checking.

164. Part Completion Checklist

You are done if you can:

• distinguish configuration session from committed result;
• model session lifecycle;
• persist complete evaluation context;
• support incomplete and invalid working state;
• detect context drift;
• manage optimistic concurrency;
• preserve user versus derived changes;
• design incremental recalculation;
• support large/bulk configurations;
• and commit idempotently into quote.

165. Key Takeaways

1. Configuration is a process, not only a result.
2. Working state may be incomplete or invalid.
3. Context is part of configuration input.
4. Session and Quote Item should not be conflated casually.
5. Long-running sessions need versioning and concurrency.
6. Context drift must be visible.
7. User choices and derived changes need separate provenance.
8. Recalculation should be deterministic.
9. Commit is a versioned, idempotent transformation.
10. Internal session and context behavior must be verified.

166. References

Conceptual baseline:

• General CPQ configuration-session, guided-selling, and complex-product practices.
• Domain-Driven Design aggregate lifecycle, commands, and snapshots.
• Collaborative editing, optimistic concurrency, autosave, and branching patterns.
• Incremental computation, dependency graphs, and deterministic recalculation concepts.

These references do not define internal CSG configuration-session implementation.