Pyle

Customer Management ​

Customer Management is the domain that defines who the account is, which users belong to it, which addresses and lists it owns, and which customer-specific segmentation or restriction rules affect downstream behavior.

This is the right next documentation pass because the framework has a real customer account core, storefront self-service surfaces, admin account-management flows, export/email workflows, and a smaller but meaningful segmentation and restriction layer.

Status ​

  • [x] Domain overview written
  • [x] Subdomains reviewed
  • [x] Technical node pages linked
  • [x] End-user concept pages linked
  • [x] Task guides linked

Responsibility ​

This domain is responsible for:

  • storing the main customer account record and invitation/join-code identity
  • linking users, account managers, owners, and assigned staff to customer accounts
  • managing customer-specific address books and default shipping or billing addresses
  • managing account-owned lists and their product membership
  • applying customer segmentation and restriction data that other domains consume

Subdomains ​

  • Customer Accounts And Relationships
    • Customer
  • Segmentation And Restrictions
    • CustomerGroup
    • CustomerProductRestriction
  • Customer-Owned Records
    • Customer Address
    • CustomerList
    • CustomerListProduct
    • Wishlist
  • Folded Account Team And Access Surfaces
    • User
    • user_customer
    • storefront team and permissions flows

Classification Decisions ​

Standalone technical pages ​

Standalone end-user pages ​

Standalone task guides ​

Folded into parent pages for now ​

  • CustomerListProduct
    • folded into Customer List
  • Wishlist
    • folded into Customer List because the packaged product already includes a wishlist-to-list migration path and the newer list system is the stronger surfaced workflow
  • customer-linked users, team membership, invitation flow, and storefront permission management
    • folded into Customer
  • CustomerCard and payment-gateway links
    • folded out of this domain and kept under Payments & Billing

Explicitly deferred or clarified ​

  • the separate CustomerAddress model/table
    • exists in the framework, but the packaged admin and storefront customer-address flows operate on the generic Address model and expose it through CustomerAddressResource
  • a standalone end-user Customer Groups page
    • deferred because this sprint did not find a dedicated packaged operator workflow that would make a non-technical page genuinely useful
  • standalone user, role, or permission pages inside this domain
    • deferred because those capabilities overlap with Supporting Platform Capabilities even though customer-facing team surfaces exist

Priority Technical Pages ​

Priority End-User Pages ​

Priority Task Guides ​

Evidence Highlights ​

Framework ownership ​

  • packages/framework/src/Models/Customer.php
  • packages/framework/src/Models/CustomerGroup.php
  • packages/framework/src/Models/Address.php
  • packages/framework/src/Models/CustomerList.php
  • packages/framework/src/Models/CustomerListProduct.php
  • packages/framework/src/Models/Wishlist.php
  • packages/framework/src/Models/CustomerProductRestriction.php
  • packages/framework/src/Models/User.php

Admin surfaces ​

  • packages/framework/src/Http/Controllers/Api/Admin/CustomersController.php
  • packages/framework/src/Http/Controllers/Api/Admin/CustomerGroupsController.php
  • packages/framework/src/Http/Controllers/Api/Admin/CustomerAddressesController.php
  • packages/admin/src/Livewire/Admin/Customers
  • packages/admin/src/Livewire/Admin/Customer
  • packages/admin/src/Livewire/Admin/Tools/Excel/ExportDialog/CustomerExport.php

Storefront surfaces ​

  • packages/framework/src/Http/Controllers/Api/Storefront/CustomersController.php
  • packages/framework/src/Http/Controllers/Api/Storefront/CustomerAddressesController.php
  • packages/framework/src/Http/Controllers/Api/Storefront/UsersController.php
  • packages/framework/src/Http/Controllers/Api/Storefront/WishlistsController.php
  • packages/storefront/src/Livewire/Storefront/MyAccount/Profile
  • packages/storefront/src/Livewire/Storefront/MyAccount/Addresses
  • packages/storefront/src/Livewire/Storefront/MyAccount/Lists
  • packages/storefront/src/Livewire/Storefront/MyAccount/Team
  • packages/storefront/src/Livewire/Storefront/MyAccount/Permissions
  • packages/storefront/src/Livewire/Storefront/CustomerList

Integration and bulk-data surfaces ​

  • packages/framework/src/Actions/Customer
  • packages/framework/src/Actions/Address
  • packages/framework/src/Actions/CustomerList
  • packages/framework/src/Actions/Exports/Customers
  • packages/framework/src/Actions/ErpBridge/Customer
  • packages/framework/src/Actions/ErpBridge/Address
  • packages/framework/src/Actions/ErpBridge/CustomerProductRestriction
  • packages/framework/src/Mail/ForCustomer/AccountRegistrationEmail.php
  • Customer is the true center of gravity for this domain. Team members, invitation flows, lists, addresses, and customer-specific downstream rules all branch from it.
  • The packaged customer-address experience uses the generic Address model. The docs keep the business label Customer Address, but the technical page will call out the implementation mismatch explicitly.
  • Customer List is a real storefront feature with create, edit, share, and product-membership workflows. Wishlist still exists, but the framework also includes a migration path into customer lists.
  • Customer Group is a real model and admin API concept, but this first pass did not yet confirm a dedicated packaged Livewire settings page for direct group management.
  • Customer Product Restriction is real and important, but the strongest evidence is integration and ERP sync, not packaged operator UI.