Register And Settings

account-bundle includes user-facing flows for account creation and account settings. They are a good starting point when you want self-service account creation without building the whole flow from scratch.

Account Registration Flow

RegisterController creates a new account through AccountManagerInterface, builds RegisterForm, dispatches events, saves the entity, and redirects to the success page.

The default registration form is intentionally small:

name

The main registration events are:

sfs_account.register.initialize
sfs_account.register.form_valid
sfs_account.register.form_invalid
sfs_account.register.success

What Happens On Successful Registration

AccountCreateListener extends the default flow:

if the current user exists and the account implements OwnerInterface, that user becomes the owner
if the account implements AccountMembershipsInterface, the listener creates a membership relation for the current user
if that relation supports roles, it adds ROLE_OWNER
if that relation supports grantedBy, it stores the current user there too

The listener uses the current membership interfaces. A custom account type must expose and initialize its membership collection for this automatic membership to be created.

Redirect After User Registration

UserRegisterListener listens to:

sfs_user.register.success
sfs_user.invitation.accepted

When the registered user implements UserAccountMembershipsInterface and still has no accounts, the listener redirects the user to sfs_account_register.

That creates a simple onboarding flow:

create the user
create the first business account

Custom Registration Journeys

The default registration flow is intentionally small so you can adapt it without replacing everything.

Common customizations are:

set status, type, or owner during sfs_account.register.initialize
create related data during sfs_account.register.success
redirect to a domain-specific dashboard instead of the default success page
branch by account type such as Provider or Corporate

For multiple account types, replacing AccountManagerInterface is often the cleanest solution.

Account Settings

SettingsController edits the current account resolved from the request. The default form contains one field:

name

It dispatches:

sfs_account.settings.form_valid
sfs_account.settings.form_invalid
sfs_account.settings.updated

This is a good base when you want a simple editable account profile and then need to add your own fields later.

Settings Users List

The bundle also includes a members page for the current account. It works when the account implements AccountMembershipsInterface.

The controller passes the account's memberships to the template. The bundled template displays usernames; override it if your users log in only by email or need another display label.

User Accounts List

User\AccountsController shows the accounts for the current user. In the current implementation it expects the authenticated user to implement UserAccountMembershipsInterface.

This is useful for classic "switch between accounts" experiences, and uses app.user.accountMemberships in the template.

When To Keep The Built-In UI

The bundled pages are a good fit when:

your account model follows standard Softspring conventions
you want a fast starting point
you are happy to extend forms or templates later

If your onboarding, membership rules, or account types are very specific, keep the controllers only as a reference and move sooner to custom services and pages.