Skip to main content
Agatabo organizes everyone in your tontine into a single Organization Users list, but not everyone has the same relationship to the group. Some people are here to save money and access loans — those are your members. Others run the day-to-day operations as treasurers, accountants, or administrators — those are your staff. Understanding this distinction is the foundation of everything you do in the Users section, from issuing invitations to configuring permissions and reviewing financial history.

Members vs. Staff

A member is an organization user who participates directly in the tontine’s savings and lending activities. When you assign someone the Member role, Agatabo automatically creates a savings ledger account for them, enabling deposits, withdrawals, loan applications, and dividend distributions.A member:
  • Has login credentials (phone number required; email optional)
  • Holds the Member role, giving them access to their own financial data
  • Accumulates a savings balance through regular contributions
  • Can apply for and receive loans from the organization
  • Receives a share of dividends when your organization distributes profits
  • May also hold additional operational roles (for example, a member who also serves as Treasurer)
Key point: Every member is an organization user, but not every organization user is a member. Your treasurer might be purely operational staff, or they might save alongside their administrative duties.

User Lifecycle

Every person you add to your organization moves through the same lifecycle, from invitation to eventual departure.
1

Invitation

You create the user’s profile in Agatabo and send an invitation via email, SMS, or a manually shared link. The user does not yet have a password and cannot log in.
2

Account Activation

The invited person clicks the activation link (valid for 72 hours), sets a secure password, and is automatically logged in for the first time.
3

Active User

The user can now log in with their email or phone number and perform all actions permitted by their assigned roles.
4

Role Updates

As responsibilities change — a long-standing member becomes Treasurer, or a Loan Officer leaves that position — you add or remove roles at any time. Permission changes take effect immediately.
5

Deactivation

When a user leaves your organization, you deactivate their account. They lose access to all organization resources, but all historical data is preserved for audit and reporting purposes.

User Status

An inactive user can technically still authenticate with Agatabo (their password remains valid), but they cannot access any features or data within your organization. To fully remove someone’s access, you must deactivate their organization account, not just remove their roles.
StatusWhat It MeansCan Log In?Can Access Organization?
ActiveAccount is enabled and fully operational✅ Yes✅ Yes
InactiveAccount has been deactivated✅ Yes (credentials intact)❌ No (all permissions denied)
Invitation status is tracked separately and independently of account status:
Invitation StatusMeaning
PendingInvitation sent; user has not yet activated their account
AcceptedUser has set a password and logged in at least once
RevokedInvitation was cancelled before it was accepted

Financial Information Tracked Per Member

Once a user holds the Member role, Agatabo tracks the following financial data on their profile:
CategoryWhat Is Tracked
Savings BalanceReal-time ledger balance (total deposits minus withdrawals)
Deposit HistoryEvery contribution with date, amount, and bank account
Active LoansCurrent outstanding loans with principal, interest, and penalty detail
Loan HistoryAll past loans, repayment status, and disbursement records
Entry FeeOne-time membership fee, if recorded
Dividend AllocationsEach distribution received from profit-sharing pools

Permissions System Overview

Agatabo uses role-based access control (RBAC). Every action in the platform — viewing a savings balance, recording a deposit, approving a loan — is governed by a permission. Permissions are bundled into roles, and users inherit all permissions from every role they hold. Permission names follow the format resource:action, for example:
  • savings:read — view savings data
  • savings:write — record deposits
  • loans:write — create and manage loans
  • organization_users:write — invite and manage users
Each permission also carries a scope that controls whose data it applies to:
  • SELF — the user can only access their own data
  • ANY — the user can access data for all members in the organization
When a user holds multiple roles, the most permissive scope always wins. If one role grants savings:read (SELF) and another grants savings:read (ANY), the user effectively has savings:read (ANY).

Next Steps

Inviting Users

Add new members and staff to your tontine with a step-by-step walkthrough of the invitation process.

Roles & Permissions

Understand the built-in Administrator and Member roles, create custom roles, and learn how permissions combine.

Managing Users

Update roles, deactivate accounts, resend invitations, and handle user departures correctly.