Skip to content

User type management

This operation covers the EXT_USER_TYPE layer that hangs beneath a user account. It persists the user's roles, validates role-level business constraints, saves the related customer and access-group children, and exposes helper methods that support provider EFT administration and policyholder registration checks.

Field Value
Operation ID OP-EU-06
Trigger User-type load, save, delete, or policy/provider helper request
Inputs User type ID, user ID, customer ID, source-system identifiers, credentials, access groups, policy number, provider email
Outputs Persisted EXT_USER_TYPE row, saved child groups, helper booleans, and EFT-related updates
Primary components clsUserType.FillUserType, clsUserType.OnSave, clsUserTypeCollection.GetUserTypesByUserID, mdlCodeMaps.GetUserTypes, mdlCodeMaps.GetStatusTypes
Entry point Business\SAIF.Business.External.Users\clsUserType.vb

Steps

  1. Create or retrieve a user-type row. New rows allocate EXT_USER_TYPE_SEQ; existing rows retrieve the user type by sequence number and fill the persisted fields from EXT_USER_TYPE joined to its code tables (SQL-009, SQL-030, EXT_USER_TYPE).
  2. Load the type and status code maps. mdlCodeMaps.GetUserTypes caches the EXT_USER_TYPE_CODE map, while mdlCodeMaps.GetStatusTypes caches and orders the EXT_USER_STATUS_CODE map used by the broader user aggregate (SQL-038, SQL-039, EXT_USER_TYPE_CODE, EXT_USER_STATUS_CODE).
  3. Load all user-type definitions for selection UIs when needed. GetAllUserTypes reads the type code and prompt tables into placeholder rows that describe the required source-system inputs for each type (SQL-031, EXT_USER_TYPE_CODE).
  4. Load a user's role assignments through the API projection. GetUserTypesByUserID calls ExternalLogin/UserTypesByUserId/{id}, then FillUserType hydrates each API record into a clsUserType, rehydrates access groups, and sets IsSteward from the steward access-group selection.
  5. Validate source-system and collection rules before save.
  6. New rows require CustomerID > 0.
  7. Collection rules allow only one primary type, only one steward, and only one row for the same user type and source-system group.
  8. Policyholder rows require a numeric policy number.
  9. Agency steward rows cannot also select ARP Agency or Producer access.
  10. Validate policyholder access helpers when access groups are chosen. ValidateStateAgencyAccess requires entity code 50 before the state-agency group can be selected, and ValidateWrapUpAccess requires the policy to be the wrap-up parent before Wrap-Up Online can be selected.
  11. Insert or update the EXT_USER_TYPE row. BeforeInsert and BeforeUpdate bind user, customer, role, and source-system fields into EXT_USER_TYPE; update uses the UPDATE_NUM concurrency pattern (BR-EU-05, SQL-009, SQL-050, EXT_USER_TYPE).
  12. Delete the row when the user type is removed. BeforeDelete removes the EXT_USER_TYPE row by sequence number (SQL-056, EXT_USER_TYPE).
  13. Save child objects around the row change. OnSave always saves the related customer, deselects and saves all access groups when the row is being deleted, and saves provider EFT child objects when they were loaded. OnSaveComplete saves the access-group collection after the root insert or update.
  14. Support provider EFT admin handoffs. UpdateAdminUserEmail finds the current admin user type for a provider and reassigns matching provider EFT rows to the current user type (SQL-032, EXT_USER_TYPE).
  15. Update authorization-contact emails for active provider EFT rows. UpdateEftAuthorizationEmail loads the provider EFT collection for the source-system group and updates active PAYMENT_AUTHORIZATION rows with the new email and audit stamp (SQL-051, PAYMENT_AUTHORIZATION).
  16. Run policy/provider helper checks used by registration paths.
  17. IsQuotedPolicyExpired, IsBillingPlanEstablished, and IsBillingPlanSCInstallments invoke Oracle package functions for policyholder registration checks (SQL-033, SQL-034, SQL-035).
  18. IsUserEobOwner checks whether the AD user owns any provider EOB interface rows (SQL-036, PROVIDER_EOB_INTERFACE).

Process flow

The following diagram visualizes this operation's control flow.

flowchart TD
    Start([User-type request]) --> Load[Create or load user type]
    Load --> Maps[Load code maps and access groups]
    Maps --> Validate[Run role, policy, and collection validation]
    Validate --> Action{Save, delete, or helper check?}
    Action -->|Save| Persist[Insert or update user type and children]
    Action -->|Delete| Remove[Delete row and clear groups]
    Action -->|Helper| Helpers[Run policy or provider helper logic]
    Persist --> Done([Return user-type result])
    Remove --> Done
    Helpers --> Done

Failure and edge-case behavior

  • Primary-type and steward uniqueness are enforced at the in-memory collection layer before the database row is written.
  • State-agency and wrap-up access checks depend on live policy data; a policy that no longer meets those conditions cannot keep the corresponding access selection.
  • Provider EFT email updates only touch rows whose expiration date is blank or still current.
  • The Oracle package bodies behind the policy helper calls are not present in this repository, so database-side decision details remain unknown.**

Note: Statements marked with * were inferred from code structure, naming conventions, or contextual evidence where direct confirmation was not available in source artifacts. Statements marked with ** could not be confirmed; treat as unknown until verified.

Sources

  • Business\SAIF.Business.External.Users\clsUserType.vb
  • Business\SAIF.Business.External.Users\mdlCodeMaps.vb