2026 Q1: Advanced Integrations & AI Backlog | Sales & Pricing Extension Platform

Sales Area Access Control

Epic: 26Q1-E1

Completed

Goal: Restrict visibility of transactional data (Quotes, Customers, Locations) based on user assignments in `UserSalesAreaAccess`, ensuring users only see business data they are authorized to access. Configuration data (Sales Areas, Sales Orgs, Plants, etc.) remains fully visible to admins for easier system setup and maintenance.

Business Value:

Improved security by restricting transactional data visibility
Simplified user experience by showing only relevant customer/quote data
Prevention of data entry errors in wrong Sales Areas
Faster implementation: Admins can view and configure all Sales Areas without assignment bottlenecks
Auto-sync friendly: Synced Sales Areas from S/4 HANA immediately visible to admins

Scope Clarification (26Q1-E8 considerations):

✅ Row-Level Filtering APPLIES to:

Quotes (QuoteHeaders, QuoteItems)
Customers
Locations
QuoteTemplates
UserConfigurations (for non-admin users)

❌ Row-Level Filtering DOES NOT apply to:

SalesAreas (configuration entity)
SalesOrganizations (configuration entity)
DistributionChannels (configuration entity)
Divisions (configuration entity)
Plants (configuration entity)
DocumentTypes (configuration entity)
ConditionTypes (configuration entity)
Backend Systems (BackendType - configuration entity)

Rationale:

Configuration entities must be fully visible to administrators to:

1. View and manage auto-synced data from S/4 HANA (Epic 26Q1-E8)

2. Assign Sales Areas to users in UserSalesAreaAccess

3. Configure system without chicken-and-egg access problems

4. Compare and audit configurations across backends

Access to configuration apps is controlled by role-based permissions (@requires) in service definitions, not row-level data filtering.

Status: In Progress

26Q1-E1-01 Sales Area Dropdown Filtering
High 5 Done (2026/01/08)
As a Sales Rep or Manager
I want to only see Sales Areas assigned to me in dropdowns
So that I do not select or interact with Sales Areas I am not authorized to access.
Acceptance Criteria
- Access Control: The `SalesAreas` entity READ operation filters results based on `UserSalesAreaAccess` for the current user.
- Admin Override: `SEP_Admin` users are also subject to this check.
- Assignments: A new `AllSalesAreas` service entity is available (unrestricted) for use in the User Configuration screen to allow assigning new Sales Areas.
- Caching: User access lists are cached in-memory to minimize DB hits.
- Empty State: If a user has no assigned Sales Areas, the list is empty (and/or error).
---
26Q1-E1-02 User Access Restriction on Transactional Data
High 5 Done
As a Sales Rep or Manager
I want to see only the Quotes, Customers, and Locations that belong to Sales Areas I am assigned to
So that I do not access data outside my authorization scope.
Acceptance Criteria
- Quotes: Usage of the Quote list only shows specific quotes where `SalesArea_ID` matches one of my assigned Sales Areas.
- Customers: Usage of the Customer list only shows customers where `SalesArea_ID` matches my assignments.
- Locations: Usage of the Location list only shows locations where `SalesArea_ID` matches my assignments.
- Admins: `SEP_Admin` users are also filtered by their assigned Sales Areas (consistent with E1-01).
- Implementation: Logic is centralized and reused from the Sales Area Access Control implementation.
- Combination: Existing filters (e.g. user searching for a customer name) work in combination with this restriction (AND logic).
---
26Q1-E1-03 Bug - Dropdown Filtering Issue
P1 (High) 3 Done
As a user
I want dropdowns for master data and transactional entities to show only the options I have access to
So that I don’t see irrelevant or unauthorized options.
Acceptance Criteria
- Dropdowns for Quotes, Customers, Locations, and QuoteTemplates are filtered based on `UserSalesAreaAccess`.
- Configuration dropdowns (e.g., SalesAreas, SalesOrganizations) remain fully visible to admins.
- Filtering logic respects user roles and assignments.
- Tests cover both admin and non-admin scenarios.
---
26Q1-E1-04 Admin Reference Projections for Sales Master Data
High 5 Done
As a system administrator
I want core sales master/reference entities to be exposed consistently in the service layer
So that configuration, sync review, and downstream admin workflows do not depend on hidden or ad-hoc projections.
Acceptance Criteria
- Core reference entities such as Sales Organizations, Distribution Channels, Divisions, Sales Areas, Plants, and Document Types are modeled in the CAP schema and exposed through the service layer.
- The admin/reference model stays distinct from transactional row-level filtering applied to quotes, customers, and locations.
- The backlog explicitly recognizes this implemented foundation even if broader UI/regression validation is still open.
- Remaining work is about validation and product framing, not about inventing the reference-data service model from scratch.
---

BTP Authorization & Bounded Assistant Governance

Epic: 26Q1-E9

In Progress

Goal: Establish production-ready authorization foundations for IAS/XSUAA deployment while keeping AI capabilities bounded and auditable. Protect high-risk business actions first, without duplicating services by persona.

Business Value:

Reduces security and compliance risk before first BTP deployment
Keeps API/service model maintainable as AI and approval capabilities grow
Enables clear least-privilege assignment for Admin, Rep, and Manager personas
Improves supportability with deterministic policy checks and interaction traceability
Preserves a unified assistant UX while isolating specialist execution contexts behind a central orchestrator

Target Architecture:

Shared user-facing UX through the existing Platform Assistant and contextual action buttons
Centralized orchestrator for specialist selection, policy, context sharing, and result normalization
Isolated specialist sessions with separate prompts and tools per capability
Controlled context sharing only through the orchestrator
Preserved user identity and JWT propagation into specialist calls
Role-based authorization per specialist capability
Execution logs per specialist call
Reusable analytics services for deterministic KPI calculations

Scope:

XSUAA descriptor hardening (`xs-security.json`) with role templates and capability scopes
CAP authorization baseline (`@requires`) on high-risk entities/actions
BTP deployment onboarding (IAS trust, role collections, assignment process)
Assistant policy gating roadmap for write operations

26Q1-E9-01 P0 - Harden XSUAA Security Descriptor
P0 (Critical) 3 Done
As a platform admin
I want a valid, deployment-ready XSUAA descriptor using scopes and role templates
So that role collections can be created and assigned consistently in BTP cockpit.
Acceptance Criteria
- `xs-security.json` uses `scopes` + `role-templates` (no deprecated/invalid role collection structure)
- Persona scopes are defined: `SEP_Admin`, `SEP_Rep`, `SEP_Manager`
- Capability scopes are added for service creep control (AI, approval, sync, pricing)
- Descriptor remains compatible with `tenant-mode: dedicated`
---
26Q1-E9-02 P0 - Guard High-Risk CAP Actions with @requires
P0 (Critical) 5 Done (Baseline)
As a security architect
I want strict authorization on critical mutation actions
So that only authorized roles can execute backend sync, approval, and pricing mutations.
Acceptance Criteria
- `@requires` added to high-risk bound actions (sync, pricing condition creation, approval)
- `BackendTypes` sync/test actions restricted to admin-level scopes
- Access matrix documented per action (Rep/Manager/Admin)
- No service duplication by persona required for enforcement
---
26Q1-E9-03 P0 - First BTP Auth Deployment Runbook
P0 (Critical) 3 Done
As a delivery engineer
I want a concrete first-deployment sequence for IAS + XSUAA
So that auth can be validated end-to-end with minimal trial-and-error.
Acceptance Criteria
- Runbook includes XSUAA binding (`mta.yaml`/`manifest.yaml` snippet), IAS trust, role-collection setup, and test-user assignment
- Includes smoke tests for allow/deny scenarios
- Includes troubleshooting checklist for missing scopes/claims
---
26Q1-E9-04 P1 - Centralize Assistant Policy Gate for Mutations
P1 (High) 5 In Progress (Baseline Implemented)
As a product owner
I want assistant-triggered write actions to pass a centralized policy gate
So that AI remains bounded, explainable, and compliant.
Acceptance Criteria
- Allowlist exists for assistant-triggered tools/actions
- Mutating operations require explicit role and policy checks server-side
- Policy denials return sanitized, user-visible reasons with interaction correlation
26Q1-E9-08 P1 - Hybrid Specialist-Agent Orchestration Model
P1 (High) 5 Planned
As a platform architect
I want assistant-facing requests to route through a centralized orchestrator into isolated specialist sessions
So that conversational UX stays unified while each specialist capability remains governed and auditable.
Acceptance Criteria
- Platform Assistant and contextual buttons keep a single user-facing UX
- Portfolio Deep Research routes through the orchestrator into a dedicated Portfolio Research Specialist
- Specialist sessions receive only orchestrator-approved context, prompt, and tools
- User identity and JWT are preserved end to end
- Specialist-level authorization is enforced server-side per capability
- Execution logs are written per specialist call with correlation IDs
- Deterministic KPI services are reused for portfolio metrics and chart/table payloads
---
26Q1-E9-05 P1 - Add Authorization Audit Telemetry
P1 (High) 3 Done (2026-02-16)
As a compliance lead
I want authorization decisions logged for sensitive actions
So that support and audit teams can reconstruct why access was allowed or denied.
Acceptance Criteria
- Sensitive action execution logs include user, scope context, decision, and timestamp
- Denials include non-PII reason codes
- Logs are queryable in admin monitoring views
---
26Q1-E9-06 P2 - Refactor Persona-to-Capability Role Mapping
P2 (Medium) 3 Done

As a solution architect
I want role collections to map stable personas to evolving capabilities
So that AI/approval feature growth does not force service-level duplication.
---

Acceptance Criteria
26Q1-E9-07 P1 - CPQMobile IAS/XSUAA Sign-in for BTP Offline Flows
P1 (High) 5 Done (2026-04-09)
As a field user
I want the mobile app to sign into the deployed BTP tenant through IAS/XSUAA
So that the offline-first architecture can work against the real cloud instance instead of only local mocked auth.
Acceptance Criteria
- `CPQMobile` supports `BTP Login` mode in backend settings.
- Login uses OAuth Authorization Code + PKCE rather than the legacy mock Basic auth flow.
- Existing offline mirror and outbox behavior remain unchanged once the bearer token is obtained.
- Local development with mocked Basic auth still works for the current local test credentials.
- Regression tests cover auth runtime normalization for both Basic and Bearer modes.
- Persona role collections documented: Admin, Rep, Manager
- Capability scopes documented and mapped to each persona
- Change process documented for adding new capabilities
---
26Q1-E9-07 P2 - Authorization Regression Test Baseline
P2 (Medium) 5 Done (2026-02-16)
As a QA engineer
I want a baseline authorization test matrix
So that future service additions do not silently bypass access controls.
Acceptance Criteria
- Matrix covers key entities/actions by role
- Includes positive and negative test scenarios
- CI-ready checklist available for pre-release validation
---
26Q1-E9-08 P1 - Intent Detection Configuration & Action/Entity Extraction Hardening
P1 (High) 5 In Progress
As a product owner
I want assistant intent detection to be fully configurable through prompt tuning scenarios and to classify actions/entities more reliably
So that we can tune assistant behavior without code deployments and improve routing quality for search vs mutation workflows.
Acceptance Criteria
- `NLP_INTENT_DETECTION` prompt/model/provider are sourced from `AIAssistantPrompt` configuration (global + SalesArea scoped) using existing prompt-loader chain.
- Seed/default prompt configuration includes an explicit `NLP_INTENT_DETECTION` scenario in `db/data/uva.CPQ-AIAssistantPrompt.csv`.
- Intent output schema includes action classification metadata (e.g., suggested operation key / mutation flag / confirmation-needed) in addition to intent/entity/query/confidence.
- Entity identification quality is improved for ambiguous inputs (quote/customer/product/plant/location) with deterministic fallback rules.
- Fallback to hardcoded defaults is only used as resilience path when prompt config is missing/unavailable, and this path is logged.
- Tests cover at least: (1) configured NLP prompt path, (2) fallback path, (3) action classification parsing, (4) entity disambiguation for ambiguous prompts.
Implementation Notes:
- Current code already loads `NLP_INTENT_DETECTION` via `promptLoader` in `assistant-logic.js`, but in practice falls back when no active prompt rows exist for that use case.
- Existing seeded prompt data currently covers greeting/search/create use cases but should be extended to include dedicated intent-detection scenarios.
26Q1-E9 Review Snapshot (2026-02-15)
Backlog

Acceptance Criteria
26Q1-E9 Talk Prep (Finish Plan)
Backlog

Acceptance Criteria

AI Assistant UX Improvements

Epic: 26Q1-E2

In Progress

Goal: Enhance the in-app AI assistant chat for readability, responsiveness, and transparency of LLM reasoning to improve user trust and ensure no messages are missed.

Business Value:

Users never miss new messages (auto-scroll to latest)
Cleaner chat UI improves scanning speed and reduces cognitive load
Optional "Thinking" details build trust and allow audit of AI reasoning
Improved security through HTML sanitization prevents XSS attacks

26Q1-E2-01 Increase Chat Bubble Spacing
Medium 1 Done
As a user chatting with the assistant
I want more vertical space between message bubbles
So that I can scan the conversation faster and distinguish between messages more easily.
Acceptance Criteria
- Message bubbles have ≥0.5rem vertical spacing (margin-bottom: 0.75rem implemented)
- Spacing works consistently on desktop and mobile viewports
- Visual separation improves readability without excessive whitespace
Technical Notes
- CSS change to `.assistantChatItem` in fragment
- No impact on existing functionality
---
26Q1-E2-02 Auto-Scroll to Latest Message
High 2 Done
As a user
I want the chat to scroll to the newest message automatically
So that I don't miss responses during streaming or when messages are added programmatically.
Acceptance Criteria
- Scroll happens after each message append (user or assistant)
- Scroll happens during streaming for each token batch
- Uses `scrollIntoView` with `requestAnimationFrame` to avoid race conditions
- Fallback to `scrollTop = scrollHeight` if `scrollIntoView` fails
- Works reliably when popover is opened, messages added, or during streaming
Technical Notes
- Refactored `_assistantScrollToEnd()` helper
- Called from `_appendAssistantMessage()` and streaming token handler
- Uses DOM `.querySelectorAll('.assistantChatItem')` to find last item
Definition of Done:
- Auto-scroll works when messages added manually
- Auto-scroll works during LLM streaming
- No scroll jitter or performance issues
---
26Q1-E2-03 "Thinking…" Indicator While Streaming
High 2 Done
As a user
I want to see a "Thinking…" indicator while the LLM is processing
So that I know the assistant is working on my request and haven't been forgotten.
Acceptance Criteria
- Indicator appears immediately when query is sent (before first token)
- Shows `BusyIndicator` with text "Thinking..." in message bubble
- Replaced/hidden when first token arrives from LLM
- If no tokens arrive within timeout, indicator remains visible
Technical Notes
- Message model includes `isThinking: true` flag initially
- Fragment conditionally shows `BusyIndicator` when `isThinking === true && content === ''`
- Flag set to `false` on first token arrival
Definition of Done:
- Thinking indicator appears before streaming starts
- Indicator disappears when content arrives
- Works on slow network connections
---
26Q1-E2-04 Collapsible LLM Reasoning (`Think` tags)
Medium 3 Done
As a user
I want the LLM's internal reasoning to be hidden by default but expandable
So that answers stay concise while I can audit reasoning when needed for transparency.
Acceptance Criteria
- `Think...Think` content is extracted from LLM response
- Thinking content shown in a collapsed section below main answer
- Link/button labeled "▶ Show reasoning" / "▼ Hide reasoning" toggles visibility
- Collapsed by default (`thinkExpanded: false`)
- Keyboard accessible (Enter/Space to toggle via Link control)
- Collapsed section has distinct styling (border, background, max-height when expanded)
Technical Notes
- `processLLMMessage()` utility extracts `Think` tags via regex
- Model properties: `hasThink`, `thinkHtml`, `thinkExpanded`
- Fragment conditionally renders collapsible section
- `onToggleThinking()` handler toggles `thinkExpanded` flag
Definition of Done:
- Think tags detected and extracted correctly
- Toggle works (keyboard + mouse)
- Styling distinguishes reasoning from main content
- Unit tests for `extractThinkSection()` regex
---
26Q1-E2-05 Sanitize Assistant HTML Output
Critical 2 Done
As a security-conscious admin
I want all LLM-provided HTML sanitized before rendering
So that XSS attacks are prevented and the application remains secure.
Acceptance Criteria
- Whitelist of allowed tags enforced (`b`, `i`, `em`, `strong`, `u`, `p`, `br`, `ul`, `ol`, `li`, `a`, `code`, `pre`, `span`, `div`, `details`, `summary`)
- Allowed attributes restricted per tag (e.g., `href`, `title`, `target` for ``)
- `javascript:` and `data:` URLs in `href` are blocked
- Unknown tags are stripped but text content preserved
- Sanitization applied to main content AND think content
- Unit tests cover edge cases (malicious scripts, nested tags, attribute injection)
Technical Notes
- `sanitizeHtml()` utility in `app/common/utils/htmlSanitizer.js`
- Uses DOM parsing + whitelist approach (not regex-based)
- Called from `processLLMMessage()` before setting model properties
- Consider adding CSP headers as additional layer
Definition of Done:
- Sanitizer utility created with unit tests
- All assistant messages sanitized before rendering
- Penetration testing confirms no XSS vectors
- Documentation added to TECHNICAL_README.md
---

26Q1-E2-06 Markdown Rendering in Assistant Chat Bubbles

P2 (Medium) 3 Done

As a sales rep reading deep research results in the Quote Assistant

I want markdown formatting (bold, italic, headings, bullet lists) to render visually styled

So that LLM responses that use `bold`, `*italic*`, `## headings`, and `* lists` are readable instead of showing raw asterisks.

Acceptance Criteria

`text` and `__text__` → rendered as `` (bold)
`*text*` and `_text_` → rendered as `` (italic)
`# H1`, `## H2`, `### H3`, `#### H4` → rendered as sized headings
`* item`, `- item` (unordered) and `1. item` (ordered) → proper list rendering with indent
`` `code` `` → inline monospace code
`---` / `***` separator lines → `
` visual divider
Double blank lines separate paragraphs
Sanitizer whitelist updated to include `h1`–`h4`, `hr`
CSS styles added for all new elements inside `.assistantBubble`
User messages are also processed (markdown in user input renders consistently)
No regression in `` collapsible section or XSS sanitization

Technical Notes
`markdownToHtml(text)` pure-function added to `app/common/utils/htmlSanitizer.js`
Called inside `processLLMMessage()` before `sanitizeHtml()` to preserve generated tags
Inline version in `ObjectPageExt.controller.js` updated to match
New CSS classes in `app/quotes/webapp/css/assistant.css` scope styles under `.assistantBubble`
Uses simple line-by-line regex approach (no external libs needed)
Definition of Done:
Markdown converted to HTML before sanitizing and model binding
Visual review of deep research output shows styled headings, bold, bullets
XSS sanitizer still rejects injected `