Administration, Security & Operations

1. Approval Workflows

Approvals are a cross-cutting capability that governs documents needing sign-off before they take effect. They are configured through the ApprovalWorkflowsPage, which supports multi-step chains. Each step is governed by approver-type rules and by an approval-threshold amount, so a workflow can route differently depending on the value involved.

Items awaiting a decision collect in a Pending Approvals queue (PendingApprovalsPage). This queue spans all approval-required documents — expense claims, leave, timesheets and more — so an approver has a single place to act rather than hunting through each module. Every approvable record also carries an Approval History, giving a durable account of who decided what and when.

To reduce friction on low-value items, workflows support Auto-Approve Limit and Auto-Approve Up To rules. Below the configured amount an item can be approved automatically, reserving human attention for larger or exceptional cases.

Typical workflow

1. An administrator defines a multi-step chain on ApprovalWorkflowsPage, with approver types and threshold amounts.
2. A user submits a document such as an expense claim.
3. If it falls under the auto-approve limit it is approved automatically; otherwise it enters the Pending Approvals queue.
4. Approvers act from the queue, and the outcome is recorded in the record's Approval History.

Because the same approval framework serves many modules, approval behaviour is consistent across expenses, leave and timesheets rather than reimplemented per module.

2. Organization Admin and Multi-Tenancy

SamvraCore is a multi-tenant ERP, and the administration layer is where tenancy is governed. Organisations are managed through OrganizationsListPage and OrganizationDetailPage, each organisation carrying a slug (a URL-friendly identifier) and organisation-wide settings such as logo, currency and name.

The central guarantee of the platform is multi-tenant data isolation. Every entity carries an organization_id, and PostgreSQL Row-Level Security enforces separation at the database layer. The current tenant is set per transaction: the application sets app.current_tenant through DB.WithTenantTransaction(), so queries only ever see the rows belonging to the active organisation.

User management lives alongside this. The UsersPage handles inviting members, pending invitations, resending invitations, and invitation and magic-link expiration. Roles are managed on RolesPage, which distinguishes immutable system roles from custom roles built by selecting permissions.

Role-Based Access Control

RBAC is implemented in pkg/middleware/rbac.go. It uses a 5-minute permission cache and matches permissions with wildcard resource:action patterns. Authentication issues JWT access and refresh tokens from pkg/jwt/. Users have profile information and a profile photo (JPG, GIF or PNG up to 2 MB), and account recovery is supported through Security Questions and a password-reset flow. Together, organization_id plus Row-Level Security plus RBAC form layered protection: tenancy isolates data, roles constrain actions.

3. Backups, Audit Trail and Localisation Admin

Three administrative services keep an installation safe, accountable and global.

Backups are configured on the BackupsPage, which manages schedules and destinations. Destinations are provided by pkg/backupdest/ and support local and S3 targets, while pkg/backupschedule/ runs backups on a schedule. This mirrors the storage choices used for documents, giving operators a consistent model for where the platform writes large data.

The Audit Trail is a core accountability feature. The AuditLogPage presents every meaningful action, each entry recording a timestamp, the user, the IP address and before/after values. The audit service lives in pkg/audit/, and audit logging is applied on state-changing endpoints, so the record of change is captured systematically rather than ad hoc.

Internationalisation administration

The InternationalPage manages a 22-locale registry. The backend locale registry in pkg/locale/locale.go holds 22 locales, each with its native name, English name, script and an RTL flag, and the frontend mirrors this through a SUPPORTED_LOCALES registry. Admins therefore govern language support from a single place, with right-to-left handling built into the registry rather than bolted on.

Taken together, backups protect against data loss, the audit trail provides a defensible record of who did what, and the locale registry keeps the product usable across the markets it serves.

4. The Super-Admin Console

Above individual organisations sits a platform-level console for the operator who runs SamvraCore for many tenants. The ManageDashboard is its entry point, and from there a super-admin can govern organisations and their users across the whole platform. This is a distinct scope from the Organization Admin seen inside a single tenant: the super-admin works across every organisation at once, which is why its audit view is explicitly platform-wide rather than limited to one tenant's records.

The console groups several cross-organisation capabilities:

• Manage Organizations (ManageOrganizations, ManageOrganizationDetail) — oversight of every tenant.
• Manage Users (ManageUsers) — user administration across organisations.
• Manage Subscriptions (ManageSubscriptions, ManageSubscriptionDetail) — the commercial relationship with each tenant.
• Manage Audit Logs (ManageAuditLogs) — platform-wide, not just one organisation.
• Manage Settings and Manage Support Staff.

Impersonation with accountability

A notable capability is Manage Impersonation Sessions (ManageImpersonationSessions), which lets an administrator impersonate an organisation's users — but with a full audit trail recorded in impersonation_session.go. This matters because impersonation is a powerful support tool that can also be a security risk; binding it to an audit trail means every impersonation is traceable. The super-admin console thus balances broad operational power with accountability, extending the same audit discipline used within organisations to the platform level where the stakes are highest.

5. Updates, Telemetry, Health and Help

Four operational features keep a running installation current and observable.

The In-App Updater is admin-triggered from the UpdatesPage, which shows the current version and offers check and install actions. Three admin endpoints under /api/v1/admin/updates cover status, check and install. The update manifest is fetched from https://downloads.samvracore.tech/samvracore-erp/latest.json. Installation is careful: the binary is verified by SHA-256, swapped in place, the response is flushed after about 1.5 seconds, the process calls os.Exit(0), and systemd or the Windows SCM respawns it. A cmd/updater-probe validates manifests without admin authentication.

Telemetry includes Confirm-Dialog Telemetry (ConfirmDialogTelemetryPage) tracking destructive-action confirmations, supported by background jobs in pkg/jobs/ such as a confirm-event aggregator, an e-file status poller and a nomination-refile scanner.

Health probes and in-app help

Health endpoints make the service orchestration-friendly: GET /api/v1/health returns full status (DB, Redis, dependent services), while /health/live and /health/ready are liveness and readiness probes designed for container orchestration, load-balancer checks and uptime monitoring. In-App Help serves categories and articles via /api/v1/help/categories and /api/v1/help/articles (with search), consumed by the HelpPage; its content is bundled with the binary, so there is no dependency on an external documentation site.

6. Public Site and Subscription Billing

Not everything the platform serves is behind authentication. The Public Site comprises a LandingPage, a PublicPricingPage, a ContactPage and a SplashScreen. The contact page classifies inquiries by type — general, enterprise, partnership, custom-solution and technical-question — so incoming interest is routed by intent. A MaintenancePage provides a maintenance mode with an admin-configurable message, used when the service is intentionally offline.

Subscription Billing turns the product into a commercial service. Plans are presented on the PricingPage with monthly and yearly pricing, and a PaymentHistoryPage records what has been paid. Payments are processed through a Razorpay integration in pkg/payment/razorpay/, and there is a plan upgrade flow for moving between tiers.

Subscription health and limits

Each organisation has subscription information attached to it, including storage usage, user-count limits and an upgrade prompt. The platform tracks subscription health and recognises trial and trialing states, so an organisation can begin on a trial and be guided toward a paid plan. Billing ties back to the super-admin console, where Manage Subscriptions gives the operator oversight of each tenant's commercial status. The public site brings prospects in; subscription billing and its per-organisation limits govern what they can use once they are tenants.

7. Release Pipeline and Security Posture

SamvraCore ships as a single self-contained binary, and its release process reflects that. Distribution runs through a dedicated download server, samvracore-downloads at downloads.samvracore.tech. Releases follow a three-stage flow: deploy/upload-release.sh, then deploy/upload-pointer.sh, then deploy/promote-release.sh. A URL rewrite at ingest means the build pipeline does not need to know the canonical host, and rollback is simply re-promoting the previous version. The reference production host samvracore.tech runs on a Linux VPS under systemd with Restart=always, deployed by an SCP-plus-symlink-swap method. Local build archives are cleaned with a recoverability guard, and releases are published on GitHub.

Security posture

Security is layered throughout. Passwords are hashed with bcrypt at cost 10, and sensitive fields use AES-GCM encryption from pkg/encryption/; the portal-credential vault adds per-organisation key derivation. Authentication uses short-lived JWT access tokens with rotating refresh tokens, and RBAC middleware invalidates its cache when a role or permission changes. Audit logging covers every state-changing endpoint, and Row-Level Security acts as defence-in-depth alongside application-layer tenant filtering. The embedded HTTP server supports TLS, and pkg/middleware/ provides CSRF protection, rate limiting and IP-allowlist controls. The install wizard is hardened with an .installed marker and an atomic config write, closing the gap between installation and a secured running service.