AIUNIFY Assistant contains two separate user-management concepts:
However, the current source shows that the team-sharing interface is not fully connected to the application’s resource-access rules.
The application stores these sharing fields on a User record:
An administrator-facing Users page can select and display these values. However, the current Leads, AI Agents, and Campaigns routes continue to grant access primarily according to resource ownership rather than those sharing fields. Shared Access should therefore be treated as an unfinished or partially implemented feature in the current build.
Each person accessing AIUNIFY Assistant should have an individual account containing:
Resources are generally connected to the account that created them.
The reviewed source does not contain a separate organization or team model connecting:
Instead, each account exists as an independent platform User.
The current system does not clearly store:
The application’s primary backend User roles are:
The backend User model does not include a stored member role.
This differs from the unfinished Team Users interface, which presents:
as its visible choices.
The normal Sidebar contains:
Administrators additionally see:
The current Sidebar does not contain a normal:
menu item.
The Admin link appears only when the locally stored user record identifies the person as:
or:
Normal users do not see the Admin link.
Routes beginning with:
are protected in the frontend.
A user who is not an Administrator or Super Administrator is redirected to the Dashboard.
The backend also protects administrative actions and returns:
when an unauthorized account attempts to use them.
The source contains a separate page at:
with the heading:
and description:
However, this page is not linked from the current Sidebar or Admin navigation.
It should be treated as a legacy, unfinished, or development-stage interface rather than a dependable production Team page.
A standard account has:
A User can operate the ordinary customer sections available through the Sidebar but cannot use administrator-protected backend routes.
An Administrator has:
The Administrator passes the backend Admin check and can access the Admin area.
This includes powerful platform-level capabilities such as:
Super Administrator status is stored separately:
It is not a third value inside the primary role field.
A Super Administrator normally also has:
The public registration process checks the total number of User records.
When the database contains no users, the first registered account receives:
Later public registrations receive:
The submitted role is not used to override this first-user rule.
The normal administrative Add User form allows:
It does not provide:
as a selectable role.
A normal administrator should not assume that creating another Admin also makes that person a Super Administrator.
Both an Administrator and Super Administrator pass the general Admin middleware.
However, several operational routes treat Super Administrators differently.
Examples include broader visibility into resources that normal accounts see only by ownership.
An ordinary Administrator should not be assumed to have the same global operational-resource access as the Super Administrator.
The backend authorizes Admin operations when:
Otherwise, access is rejected.
This backend check is more authoritative than whether a link happens to appear in the browser.
Hiding an Admin link does not itself secure the application.
AIUNIFY Assistant also validates administrative permission on protected backend requests.
This prevents a normal user from obtaining administrator data merely by manually entering an Admin API address.
The Sidebar and frontend route checks read User information stored in the browser.
When a role changes, the browser may temporarily contain an older role value.
After changing a user’s role or status, the affected person should:
The backend uses the current database User during authentication, but the browser interface can remain visually stale until its locally stored User information is refreshed.
For an Administrator:
The Admin page describes its function as:
This is global platform User Management, not a business-specific team list.
The Admin User table contains:
The User column displays:
The Role column displays:
A Super Administrator receives a distinct:
badge.
The Plan column displays the User’s assigned Plan.
When no Plan is populated, the interface displays:
The Status column can display:
A red status indicates that the account itself has been deactivated.
Plan status and account activation are separate conditions.
Joined displays the date the User record was created.
It does not represent:
The Admin page includes:
The search is applied to the currently loaded User list.
The search compares the entered text with the User’s Name without case sensitivity.
The same search field compares the entered text with the User’s Email Address.
The current User Management page does not provide separate filters for:
Use the Name or Email search and review the table columns.
Select:
to open:
The form explains:
The form contains:
Enter the individual’s actual business name.
Recommended:
Avoid:
Each User must have a unique Email Address.
The backend returns:
when the address is already registered.
The Admin form requires an initial Password.
The placeholder recommends:
The Administrator should transmit the initial credentials securely.
The current Add User route directly creates an account.
It does not show an automated:
The Administrator is responsible for securely providing the initial sign-in information.
The functioning Admin form allows:
Choose User for ordinary account access.
Choose Admin only when the person requires platform-level administrative capabilities.
The Plan selector contains:
and the active Plans configured by the platform Administrator.
A selected Plan controls resource limits such as:
After reviewing the fields:
The backend creates default Settings for the new account.
Use the standard User role when the person only needs to operate:
for that account’s resources.
Assign Admin only when the person is authorized to:
The current Admin role is not restricted to one organization or department.
The administrative User-list endpoint returns all platform Users.
Do not grant Admin merely because someone supervises one Campaign or sales team.
From the User’s Actions menu:
Selecting the no-Plan option causes the backend to:
Assigning a Plan causes the backend to:
When no explicit expiration date is supplied, the current route defaults the expiration to approximately one year from the update date.
Changing a User’s Plan does not transfer:
between accounts.
It changes capacity and subscription status.
The Actions menu displays:
for an active account.
Selecting it changes:
A deactivated User can no longer authenticate successfully.
Protected API requests are rejected with a message explaining that the account has been deactivated.
The browser can redirect the person to:
For a deactivated account, the Actions menu displays:
Selecting it restores:
Reactivating an account does not automatically:
Review the Plan and operational configuration separately.
The current Admin User Management page does not provide:
Deactivation is the supported visible action for disabling access.
This reduces the risk of unintentionally destroying a User record connected to historical activity.
The separate /users page was designed to display:
It also contains:
dialogs.
Users cannot reach this page from the normal current navigation.
Direct access requires manually entering the route or using a custom link.
The page identifies itself as:
and its backend User-list and User-update routes require Admin access.
The page’s backend request retrieves all User records.
It is not scoped to:
The legacy Create User dialog presents:
The signup backend accepts:
It does not accept:
Selecting Member can fail validation because member is not an accepted backend role or User-model value.
The resulting error can contain validation wording indicating that Role must be one of the accepted values.
Selecting Admin passes the signup schema, but the current signup process independently calculates the role:
Therefore, selecting Admin in this legacy dialog does not reliably create another Administrator.
Administrators should use:
rather than the legacy /users Create User dialog.
The Admin Add User route properly accepts:
roles.
The /users table contains a Pencil action that opens:
with the description:
The dialog contains:
The dialog presents:
but the backend update route accepts:
Selecting Member is therefore incompatible with the current backend validation.
A User whose stored role is:
can open in an Edit dialog whose available choices are only Admin and Member.
This is another indication that the legacy Team interface and the current backend role model are not aligned.
The Edit User dialog labels the feature:
Its apparent intended purpose is to grant a User access to Leads carrying selected Tags.
Example:
When the Edit dialog opens, it retrieves Leads available to the signed-in Administrator and extracts their unique Tags.
Those Tags appear as selectable badges.
The Administrator can also type a Tag and select:
This adds the text to the target User’s sharedTags array.
The current Leads route retrieves normal User Leads using:
It does not consult the signed-in User’s:
array.
Therefore, saving a Shared Tag does not currently prove that the User can see or manage Leads with that Tag.
The current Shared Tags interface does not distinguish:
No granular Lead permission is stored.
The dialog permits a manually entered Shared Tag even when no Lead currently carries that Tag.
Saving it stores the text but does not create or retag any Leads.
The Shared Agents section appears intended to make selected AI Agents available to another User.
The Edit dialog retrieves AI Agents available to the Administrator who opened the dialog.
The Administrator can select or deselect each Agent.
Selected Agent IDs are stored in:
on the target User record.
When the Users list is retrieved, those IDs are populated with Agent Names for display.
The operational AI Agent route retrieves Agents using:
for a normal account.
It does not include Agent IDs stored in:
Therefore, the current sharing record does not grant confirmed Agent access through the standard Agents page or API.
The current sharing field does not distinguish:
Even after Agent sharing is fully implemented, an Agent can depend on:
The current User-sharing model does not contain equivalent sharing fields for those dependencies.
Shared Campaigns appears intended to provide another User access to selected Campaign records.
The Edit dialog retrieves Campaigns available to the Administrator who opened it.
Selected Campaign IDs are stored in:
on the target User.
The Campaign routes retrieve normal User Campaigns through:
They do not include records listed in the User’s:
array.
Saving Shared Campaigns therefore does not currently provide confirmed Campaign access through the normal Campaigns interface.
The sharing record does not distinguish:
A Campaign depends on:
Sharing only the Campaign ID would not automatically grant access to all those resources.
The current design does not define how those dependencies should be resolved for a shared User.
The legacy Users table can display:
assigned to each User.
When no sharing values exist, the column displays:
When an Agent or Campaign ID cannot be populated into an active record, the Users table can display:
This can occur when the referenced resource was removed or cannot be resolved.
A Tag, Agent, or Campaign appearing under Shared Access confirms only that its value is stored on the User record.
It does not confirm that the resource routes actually authorize access.
For normal users, operational resources are generally returned according to ownership.
Examples include:
A normal User sees Leads whose:
matches the signed-in User.
Lead updates, bulk Tags, and deletions are also ownership-scoped.
A normal User sees and manages AI Agents created by that User.
When an Agent references a Phone Number or Knowledge Base, the backend also verifies that those resources belong to the same User.
A normal User sees and manages Campaigns whose:
matches the signed-in User.
Campaign creation verifies ownership of:
Adding a resource ID to another User’s sharing array does not change:
on the actual resource.
The original creator remains the owner.
Plan usage counts are also ownership-based.
The Usage endpoint counts resources such as:
Shared-resource metadata is not included in those usage calculations.
Every newly created User receives a separate Settings record.
That record can contain the User’s own:
Creating a second User does not automatically provide access to the first User’s:
Even if Shared Agents becomes operational, a shared User’s Settings and credentials remain separate unless additional development explicitly defines credential ownership.
Do not assume a shared Agent will automatically call through the Agent owner’s provider credentials.
Each User can have an individual:
The current source does not define pooled team limits such as:
Usage belongs to individual User records.
An Administrator’s Plan does not automatically apply to accounts created by that Administrator.
Assign or verify the Plan for each User separately.
A person can register through the public Signup page.
Except for the first database User, the new account receives:
An Administrator can create an account from User Management and select:
This is the preferred current method when the platform operator is provisioning access directly.
A new Google-authenticated account is assigned according to the same first-user concept:
The current source does not provide a team owner with an interface that sends:
Every staff member should have a separate account.
Do not create one shared login for an entire department.
Use:
unless the person genuinely requires platform Administration.
Review the staff member’s expected:
and assign the appropriate Plan.
Because ownership controls access, create or import operational resources under the account that will use them.
Examples:
Do not assign Shared Tags, Agents, or Campaigns and assume that the target User can operate them.
Test the result by signing in as the target User before announcing that access has been granted.
When evaluating sharing behavior, use:
Do not test unfinished permissions with active customer Campaigns.
Each person should use:
This improves accountability and makes it possible to deactivate one person without affecting the rest of the staff.
Avoid:
An Administrator can manage platform Users and Plans.
Granting Admin access can allow the person to:
The Super Administrator account should have:
Provide initial Passwords using an approved secure method.
Do not send the Email Address and Password together in an unsecured public channel.
When a person leaves:
Deactivating an AIUNIFY User does not automatically rotate:
Review external credentials separately.
Check:
Sign out and sign back in after a role change.
The backend does not recognize the signed-in account as:
or:
Confirm the User record and sign in again.
Determine which creation form was used.
The legacy /users dialog submits to public Signup, whose current logic assigns every non-first account the User role regardless of an Admin selection.
Use Admin → User Management → Add User for reliable role assignment.
The current backend does not support:
as a User-model role.
Use the functioning:
role through the Admin User Management page.
A normal user role can enter the legacy /users page directly, but the page stops before requesting the protected User list.
Because its visible Access Denied condition checks for member rather than user, the page can appear empty instead of displaying the intended denial screen.
This does not grant backend access.
Check:
The Admin Users route is protected.
This is consistent with the current implementation.
The Shared Tag is stored on the User, but the Leads route remains ownership-based.
The Shared Agent relationship can appear in the legacy Users table while the target User’s Agents page still returns only owned Agents.
The Campaign ID can be stored under Shared Access, but the target User’s Campaign route does not currently consult sharedCampaigns.
The referenced Agent or Campaign may have been deleted or may no longer populate successfully.
Remove the stale sharing value through the legacy Edit dialog only when the interface is being used under developer supervision.
Even after the Campaign ID is stored as shared, the target User may not own:
The Campaign backend continues to enforce ownership and provider configuration.
Campaign creation verifies that every selected Lead belongs to the signed-in User.
A Shared Tag value alone does not satisfy that ownership validation.
There is no stored distinction between:
The current sharing model does not define which actions are permitted.
For example, a Shared Campaign record does not specify whether the User may:
The User model stores sharing arrays only for:
It does not contain equivalent arrays for:
The current interface does not show:
Shared Access values do not contain:
Saving Shared Access does not show an invitation or notification sent to the target User.
Until team sharing is completed and tested, operate each account as a separate workspace.
Before launching:
should align with the signed-in User.
Do not assume that an Administrator can create a resource under one account and make it fully operational for another account merely by adding it to Shared Access.
Do not delete and recreate Users merely to move resources.
Deleting or changing records without a migration plan can damage:
Use:
Select:
unless administrative access is formally approved.
Choose the Plan appropriate for the account’s expected activity.
Send the initial Email and Password using an approved process.
The new User should configure:
where applicable.
The User should then create or import:
inside that account.
Confirm that the User:
Before deactivation, review:
Stop or transfer authorized operational activity before disabling access.
Preserve required:
Use the Admin Actions menu and select:
Rotate any external credential the person could access.
Attempt an authorized verification that the former account can no longer sign in or use protected requests.
Confirm:
Confirm:
Confirm:
Confirm:
Before representing a resource as shared, confirm:
In the current build, this checklist will generally reveal that the stored sharing values do not yet grant complete operational access.
Confirm:
The current production-oriented Admin interface supports:
The current legacy Team interface contains:
but contains significant mismatches:
At present, AIUNIFY Assistant should be operated using:
The Shared Access fields should not be treated as a complete team-collaboration system until the resource routes, permissions, dependencies, and User-role model have been completed and tested.
At the end of this chapter, the user should understand the difference between a normal User, Administrator, and Super Administrator; how the first registered account receives Super Administrator status; how the Admin User Management page creates accounts, assigns roles and Plans, searches Users, and activates or deactivates access; why the Admin role is a global platform responsibility rather than a limited department-manager role; and why each User currently operates with separate Settings, credentials, Plans, usage, and owned resources.
The user should also understand that the source contains a separate legacy Users page with Shared Tags, Shared Agents, and Shared Campaigns, but that its visible Member role conflicts with the backend user role. The legacy Create User dialog does not reliably honor its selected role, and the current Leads, Agents, and Campaigns routes do not use the stored sharing arrays when authorizing resource access.
The current reliable rule is:
not: