Users and Roles

Last verified with: 10.8.6.0

OVerview #

Users, Roles, and Role Groups form the access-control foundation of LogiSense Billing.

Together, they determine who can access the platform, how they authenticate, and what they are allowed to do once they are inside. This structure is important because billing platforms often need to support many different types of users, from finance teams and operations staff to customer support teams, administrators, integration users, and single sign-on managed enterprise users.

Rather than forcing every person or integration into the same access model, LogiSense Billing separates identity from permission design. That makes security easier to manage, makes access more reusable, and helps organizations scale administration as teams and integration needs grow.

The Core Structure #

At a business level, the model works in three layers:

1. A User is the individual person or system identity that logs in.
2. A Role represents that user’s business function.
3. One or more Role Groups define the actual permissions that role receives.

This layered structure is valuable because it separates who someone is from what they can do.

Instead of configuring permissions individually on every user, organizations can create reusable roles and permission groups, then assign users to the right role as their responsibilities change.

Users #

A user is the identity that accesses the system.

Users carry the login and profile information associated with that identity, such as:

• username,
• email address,
• first and last name,
• display name,
• locale,
• time zone,
• status,
• and the assigned role.

Users can also be configured differently depending on how they access the system. Some users are interactive application users who log into the Admin Portal. Others are API-only users intended for integrations. In SAML-enabled environments, some users are managed through the organization’s identity provider instead of being administered fully inside the platform.

This gives businesses flexibility to support both human users and machine users in a consistent access framework.

Roles #

Roles define the business function of a user.

A role might represent an administrator, finance user, operations user, customer support user, developer, or another internal function. The role itself is not where all permissions are modeled. Instead, it acts as the reusable container that gathers together the right permission sets for that type of user.

This is helpful because most organizations do not want to manage every user’s access independently. They want reusable access patterns that reflect real job functions.

In practice, a role becomes the business-friendly label for a permission model. When a user changes responsibilities, the organization can often change the assigned role rather than rebuilding access from scratch.

Role Groups #

Role Groups are the building blocks that define permissions.

They are where access is actually modeled. A role group can be configured for application access or for API access, and a role can include one or more role groups depending on what that role needs.

For application users, role groups control access to menus and screens in the Admin Portal. For API users, role groups control read and write access to API areas.

This structure is powerful because it allows permissions to be assembled in a modular way. A single role can combine multiple role groups when a user needs access across more than one business area. For example, a role may need both finance permissions and customer-account permissions, or both operational permissions and reporting permissions.

That reuse reduces administrative effort and makes permission design easier to govern over time.

How They Work Together #

From a business perspective, the model is straightforward:

1. The organization defines reusable role groups for the kinds of access it needs.
2. Those role groups are attached to reusable roles.
3. Each user is assigned the role that matches that person’s business function.
4. The user then receives the permissions defined by the role groups connected to that role.

This means the permission strategy can be designed once and then reused across many users.

It also supports better governance. Security teams and administrators can reason about access in terms of approved roles and permission groups instead of reviewing one-off exceptions user by user.

Why This Structure Matters #

This model matters because billing operations usually span many teams with different responsibilities.

Examples include:

• finance teams that need billing and invoice access,
• customer service teams that need account and service visibility,
• implementation or operations teams that need setup access,
• developers or technical teams that need API access,
• and administrators that need broad system control.

Without a layered access model, access management becomes difficult to scale. Permissions are harder to review, harder to reuse, and more likely to become inconsistent over time.

By separating users, roles, and role groups, LogiSense Billing gives organizations a more durable way to manage access as their team structure evolves.

Password Policies #

For users who authenticate directly in LogiSense Billing, password policy is managed at the owner level.

This means organizations can define password requirements and login restrictions centrally for the users under that owner. Password policy covers areas such as:

• password expiry,
• password history,
• minimum length,
• complexity requirements,
• allowed characters,
• lockout behavior after repeated failed logins,
• and session timeout behavior.

This is important because access control is not only about permissions. It is also about enforcing credential hygiene and reducing the risk of unauthorized access.

Strong password policies help organizations align the platform with their broader security and compliance expectations, especially in environments where direct username and password authentication is still in use.

SAML Single Sign-On #

LogiSense Billing supports SAML-based single sign-on so organizations can authenticate users through an external identity provider.

This is especially valuable for enterprise customers that want centralized identity management across their application landscape. Instead of maintaining separate credentials inside the billing platform for every user, they can authenticate through systems such as Okta or Azure Active Directory and manage access through their existing identity processes.

From a business perspective, SAML delivers several important benefits:

• centralized authentication,
• easier onboarding and offboarding,
• reduced password management burden,
• more consistent security controls,
• and better alignment with enterprise identity standards.

In SSO environments, user records can still exist in LogiSense Billing, but key aspects of identity management are driven by the identity provider. This makes the platform a better fit for organizations that already operate with mature identity and access management practices.

How SAML Works With Roles And Role Groups #

SAML does not replace the LogiSense Billing permission model. It changes how users authenticate.

The platform still uses roles and role groups to determine what a user can do once access is granted. This is important because it keeps authorization inside a structured business model even when authentication is delegated to an external identity provider.

That means organizations get both:

• externalized identity verification through SAML,
• and structured in-platform permission control through roles and role groups.

Where identity-provider group mapping is used, role group alignment can help organizations keep access administration more consistent across systems.

When API Users Should Be Configured #

API users should be configured when access is intended for system-to-system integration rather than for a person using the Admin Portal.

An API user is useful when an organization needs an external application, middleware process, automation flow, or integration service to authenticate to LogiSense Billing and call APIs without interactive UI access.

Typical examples include:

• integrating a CRM, ERP, or order-management system,
• running scheduled data synchronization,
• automating account or service operations,
• performing bulk data operations through the API,
• or connecting external orchestration and provisioning tools.

This distinction matters because machine identities should not be treated the same as human users. API users allow organizations to separate integration access from staff access, which improves security, traceability, and permission governance.

Why API Users Matter #

Using dedicated API users provides several advantages:

• API access can be permissioned independently from UI access.
• Integrations can be isolated from employee accounts.
• Access can be granted according to the exact API responsibilities of that integration.
• Credentials can be managed and rotated without affecting human users.
• Audit and troubleshooting are easier because integration activity is tied to a dedicated identity.

This helps organizations avoid a common mistake in enterprise systems: using personal administrator accounts for integrations. Dedicated API users are the cleaner and more secure approach.

When Not To Use API Users #

API users are not the right choice when a person needs to work in the Admin Portal.

If the goal is interactive use of the application, a standard user should be configured instead. If the organization uses centralized enterprise authentication, that user may be better managed through SAML-based sign-on.

In simple terms:

• use standard users for people who work in the application,
• use SAML when those people should authenticate through the enterprise identity provider,
• and use API users for non-interactive integrations and automation.

Business Benefits #

Users, Roles, and Role Groups provide several important business benefits:

• Scalable administration. Access can be managed through reusable patterns instead of one user at a time.
• Better security control. Organizations can separate interactive users, SSO users, and API users cleanly.
• Stronger governance. Roles and permission groups are easier to review, approve, and standardize.
• Better operational flexibility. Teams with different responsibilities can receive access tailored to their function.
• Better enterprise fit. SAML support allows the platform to align with centralized identity strategies.
• Cleaner integration design. API users provide a secure and structured way to support automation and system-to-system access.

Why Customers Value This Capability #

Customers value this capability because billing platforms sit at the intersection of revenue, finance, customer data, and operations. Access to that system needs to be controlled carefully without becoming difficult to manage.

The LogiSense Billing approach gives organizations a way to:

• model access according to real business functions,
• reuse permission structures across teams,
• enforce credential and session policies,
• support enterprise SSO strategies,
• and separate human access from integration access.

That combination is what makes the access model practical. It is structured enough for governance, flexible enough for different operating models, and scalable enough for growing organizations.