b2b-saas-sap-patterns

---
name: b2b-saas-sap-patterns
description: "Design and implement enterprise B2B SaaS interfaces using SAP-style interaction patterns and information architecture. Use when building or refining admin systems, dashboards, list-detail workflows, create and edit flows, search and filter experiences, bulk operations, approval flows, or data-heavy business applications that should feel structured, efficient, predictable, and enterprise-ready."
---

# B2B SaaS SAP Patterns

Design and implement enterprise workflows with a strong preference for clarity, consistency, and task efficiency over novelty.

## Working Style

1. Start from the user's business task, not from isolated screens.
2. Prefer predictable enterprise patterns over visually expressive consumer patterns.
3. Optimize for dense but readable layouts, fast scanning, low ambiguity, and reduced operator error.
4. Reuse the same page structure and interaction model across related modules.
5. Make destructive or high-risk actions explicit, confirmable, and recoverable.

## Default Workflow

1. Identify the business object and lifecycle.
   Common examples: customer, order, invoice, contract, ticket, approval request.
2. Map the core user tasks.
   Common examples: search, filter, inspect, create, edit, submit, approve, export, bulk update.
3. Choose the page archetype.
   Read `references/page-archetypes.md` and pick the closest pattern before designing custom flows.
4. Apply enterprise interaction rules.
   Read `references/interaction-rules.md` when defining forms, tables, drawers, modals, validation, or state transitions.
5. Produce the requested output.
   This may be UX guidance, product requirements, wireframe structure, front-end code, or design rules.

## Default UX Decisions

- Use list-detail as the default model for data-heavy modules.
- Use server-backed filtering, sorting, and pagination for large datasets.
- Keep important business identifiers visible and scannable.
- Show status, ownership, time, and next action prominently.
- Prefer inline table actions for common low-risk operations and a detail page toolbar for broader actions.
- Use a dedicated page for complex creation or editing flows.
- Use modals only for short, low-risk tasks with limited fields and no complex dependency graph.
- Use steppers only when the business process is truly sequential and benefits from progress framing.

## Page Expectations

- List pages should make scanning, filtering, and batch handling efficient.
- Detail pages should open with a stable header, key attributes, status, and primary actions.
- Forms should group fields by meaning, not by backend model order.
- Dashboards should emphasize exceptions, bottlenecks, workload, and next actions rather than decorative metrics.

## Output Constraints

- Keep terminology aligned with the business domain and consistent across modules.
- Favor explicit labels over ambiguous icons.
- Preserve data density, but do not sacrifice readability.
- Avoid hidden actions for primary workflows.
- Avoid consumer-style UI tropes such as oversized hero sections, marketing cards, playful empty states, or novelty navigation.

## Reference Files

- Read `references/page-archetypes.md` when deciding whether a screen should be a list page, detail page, object page, workspace, wizard, or dashboard.
- Read `references/interaction-rules.md` when defining behavior for tables, filters, forms, approval flows, errors, confirmations, and bulk actions.
- Read `references/design-rules-examples.md` when the task is to generate or review design rules for enterprise modules.

## Deliverable Patterns

- For product or UX requests: return page structure, major components, and the rationale for the chosen pattern.
- For implementation requests: keep the visual language restrained and enterprise-oriented, with strong hierarchy and consistent action placement.
- For design-rule requests: express rules in a structured form that can be reused by agents or validators.