Last updated on April 4, 2026

Account & Settings

Control who can access what, configure system-wide defaults, manage currencies, and keep your workspace secure. This guide covers everything in the Settings area of Belvak PM.

User Roles and Permissions

Belvak PM uses a role-based access control (RBAC) system to determine what each user can see and do. Every user account is assigned exactly one role, and each role carries a set of permissions that govern access across the entire platform.

How RBAC works

Permissions are evaluated on every request - both on the frontend (which controls what buttons and actions are visible) and on the backend (which enforces access at the API level). If a user's role does not include permission to view invoices, the Invoices sidebar link is hidden, the add button does not appear, and any direct API call to the invoices endpoint will be rejected. This dual-layer enforcement means the UI always reflects the actual access a user has.

Creating custom roles

Open Settings from the sidebar and navigate to the Roles tab.
Click Add Role and give the role a descriptive name (e.g., "Account Manager", "Project Lead", "Finance Team").
The permission matrix will appear as a grid. Each row represents an entity and each column represents an action.
Toggle the checkboxes to grant or revoke specific permissions.
Click Save. The role is immediately available for assignment to users.

The permission matrix

For each entity in the system, you can independently control four actions:

View: See records in the table and open detail drawers.
Create: Add new records through the add form.
Edit: Modify existing records and update fields.
Delete: Permanently remove records.

The entities covered by the permission system include:

Projects - active work and deliverables
Clients - customer records and contacts
Invoices - billing documents and PDF generation
Payments - incoming payment records
Proposals - pre-sale proposals and quotes
Employees - team member profiles and compensation
Seekers - job applicants and recruitment pipeline
Maintenance - recurring service contracts
Purchases - company expenses and vendor costs
Suppliers - vendor and service provider directory
Referrals - referral sources and partnerships

Assigning roles to users

When creating or editing a user account, select the appropriate role from the role dropdown. Each user can have exactly one role at a time. Changing a user's role takes effect immediately - the next time they load a page, the UI will reflect their new permissions. No logout or session restart is required.

How permissions affect the UI

The frontend reads the current user's permission set on login and uses it to control visibility throughout the interface:

Sidebar links for entities the user cannot view are hidden entirely.
The "Add" button only appears if the user has create permission for that entity.
Edit and delete actions in row menus and detail drawers are hidden when the corresponding permissions are missing.
Drawer action buttons (such as "Generate PDF" or "Convert to Project") respect the permissions of the target entity.

Best practices

Principle of least privilege: Start with minimal permissions and add more as needed. It is easier to grant access than to revoke it after sensitive data has been viewed.
Separate financial roles: Create distinct roles for staff who need to manage invoices and payments versus those who only work on projects.
Limit admin accounts: Reserve full-access admin roles for one or two trusted users. Everyone else should use a scoped role.
Audit regularly: Review role assignments quarterly, especially after team changes, to ensure permissions still align with job responsibilities.

Tip: Create a "Read Only" role with only view permissions across all entities. This is useful for stakeholders or executives who need visibility without the ability to modify data.

System Settings

The Settings page is the central hub for platform-wide configuration. Access it by clicking Settings in the sidebar. Settings are organized into tabs, each covering a different aspect of your workspace.

How settings are stored

System settings are stored as key-value pairs in the database. This design makes it easy to add new configuration options over time without schema changes. When you update a setting, the change is saved immediately and takes effect across the platform on the next page load or data refresh.

Invoice template management

Belvak PM includes 12 built-in invoice template presets that cover a range of styles, from minimal to detailed layouts. Templates are stored as JSON in the database, which means you can customize every aspect of the design:

Colors and branding: Match your company's visual identity.
Column visibility: Show or hide specific line-item columns.
Footer text: Add payment terms, bank details, or legal disclaimers.
Layout options: Choose how sections are arranged on the page.

To customize a template, open the template editor in Settings, select a preset as your starting point, make your changes, and save. You can preview the result in real time using the PDF preview button before committing your changes. All future invoice PDFs will use the saved template.

Activity log

Every significant action in the platform is recorded in the activity log. This includes all CRUD operations - creating, reading, updating, and deleting records across all entities. Each log entry captures:

User: Who performed the action.
Action: What was done (create, update, delete).
Entity type and ID: Which record was affected.
Entity name: A human-readable identifier for the record.
JSON data snapshot: The full state of the record at the time of the action.

Access the activity log from the Settings page. The log is fully searchable and sortable, and can be filtered by entity type, action (create, update, delete), and user. This makes it easy to narrow down specific events even in a busy workspace - for example, you can filter to see only invoice deletions by a particular team member, or review all changes made to a specific client record. Use it to audit changes, investigate discrepancies, or track team productivity.

Database export

The Settings page also provides a database export function. This lets you download a full export of your data for backup, migration, or reporting purposes. Use it periodically to maintain an off-platform copy of your business records.

Preferences tab

The Preferences tab in Settings lets you configure default values that apply across the platform. This includes the default currency for new records, the list of available currencies, and other system-wide defaults. Setting sensible defaults here saves your team time by reducing repetitive form filling.

Tip: Configure your company details and invoice template before onboarding your team. This ensures every document generated from day one carries consistent, professional branding.

Currency Configuration

Belvak PM supports multi-currency operations out of the box. Each financial record stores its own currency code, so you can work with clients and vendors across different currencies without any workarounds.

Setting the default currency

Go to Settings and open the Preferences tab.
Find the Default Currency setting.
Select the ISO 4217 currency code you use most often (e.g., USD, EUR, GBP, AED).
Save your changes. All new records will now default to this currency.

The default currency is pre-selected whenever you create a new project, proposal, or other standalone financial record. For invoices and payments, the currency is determined by the linked project or invoice respectively, so the default currency only applies when creating entities that are not linked to a parent record.

Managing available currencies

The available currencies setting controls which currencies appear in dropdown menus across the platform. It is stored as a JSON array of ISO 4217 codes.

Adding a currency: Open the Preferences tab, add the ISO 4217 code (e.g., "CAD", "JPY") to the available currencies list, and save.
Removing a currency: Remove the code from the list. Existing records that already use the removed currency will retain their values - only new records are affected.

Note: Only add currencies your business actually works with. A shorter list keeps dropdown menus clean and reduces the chance of accidental mis-selection.

How currencies work across entities

Currency is a per-record field on all financial entities. For invoices and payments, the currency is inherited automatically from the parent entity to ensure consistency:

Projects: Each project stores its contract value in a specific currency. This is the source of truth for all downstream records. Changing a project's currency cascades the update to all linked invoices and payments after confirmation.
Invoices: Currency is locked to the linked project's currency. When you select a project on the invoice form, the currency is set automatically and cannot be changed.
Payments: Currency is locked to the linked invoice's currency. When you select an invoice on the payment form, the currency is set automatically and cannot be changed.
Proposals: Proposal values are stored with a currency code.
Maintenance contracts: Contract amounts carry a currency designation.
Purchases: Expense records include a currency field.
Employees: Salary and compensation use a dedicated salary currency field.

Why is the currency locked on invoices and payments? Allowing different currencies between a project and its invoices would make collection progress, financial summaries, and client reporting unreliable. The lock ensures that all amounts under a project can be summed and compared accurately. If you need to bill a client in a different currency, create a separate project in that currency.

Currency display formatting

The platform automatically formats currency values based on the ISO 4217 code stored on each record. This includes the correct currency symbol, decimal places, and thousand separators. For example, a USD amount displays as "$1,234.56" while a JPY amount displays as "¥1,235" (no decimals). The formatting is applied consistently in tables, detail drawers, PDF exports, and collection progress bars.

Tip: If you primarily work in one currency but occasionally deal with others, set your main currency as the default and add the others to the available list. This gives you the convenience of automatic defaults while retaining flexibility.

Security Settings

Belvak PM is built with security at every layer - from authentication and session management to API protection and rate limiting. Here is how the security architecture works and what you can do to keep your workspace safe.

Authentication with Firebase

User authentication is handled by Firebase Authentication. Users sign in with their email address and password through the login screen. Firebase handles password hashing, brute-force protection, and account lockout policies. The platform does not store passwords directly - all credential management is delegated to Firebase.

Session-based API authentication

After a successful Firebase login, the frontend sends the Firebase ID token to the server once to establish a session. The server verifies the token using the Firebase Admin SDK, creates a secure server-side session, and returns a session cookie (PHPSESSID). All subsequent API requests authenticate using this session cookie - no Firebase token is sent after the initial login. This reduces overhead and keeps the authentication flow efficient.

Session security

Session cookies are configured with multiple layers of protection:

HttpOnly: The session cookie cannot be accessed by JavaScript, preventing cross-site scripting (XSS) attacks from stealing session data.
SameSite=Strict: The cookie is only sent with requests originating from the same site, protecting against cross-site request forgery (CSRF).
Secure: In production, the cookie is only transmitted over HTTPS connections.
30-minute session regeneration: Session IDs are automatically regenerated every 30 minutes to limit the window of opportunity if a session ID is compromised.

CORS and security headers

Every API endpoint includes a standardized set of CORS and security headers. These headers restrict which origins can make requests to the API, prevent the browser from guessing content types (X-Content-Type-Options), block clickjacking attempts (X-Frame-Options), and enable XSS filtering. The headers are applied centrally, so every endpoint - whether it handles invoices, projects, or user management - receives the same protection.

Rate limiting

In production, Nginx rate limiting is enabled to protect against abuse and brute-force attacks. Rate limits are configured at the server level and apply to all incoming requests. If a client exceeds the allowed request rate, subsequent requests receive a 429 (Too Many Requests) response until the rate drops back within limits. Specific endpoints like the chatbot API also implement their own application-level rate limits (10 requests per minute) for additional protection.

Password management

Since authentication is handled by Firebase, password resets and changes go through Firebase's built-in flows. Users can reset their password using the "Forgot Password" link on the login screen, which sends a reset email through Firebase. Administrators can also reset a user's password from the Firebase console if needed.

Best practices for account security

Use strong passwords: At least 8 characters with a mix of uppercase letters, lowercase letters, numbers, and symbols.
Change default passwords: New users should change their temporary password immediately after their first login.
Limit admin accounts: Keep the number of users with full admin access to a minimum.
Review the activity log: Regularly check the activity log in Settings for unexpected or unauthorized actions.
Keep browser up to date: Modern browsers enforce security headers and cookie policies more strictly.

Note: If a user's session expires or they receive a 401 error, the platform automatically attempts to re-authenticate using the stored Firebase credentials and retries the failed request. Users are only redirected to the login screen if re-authentication fails.