← systeric.com Interwise / Docs Open App →

User Journeys

Roles & Access defines what each role can see and do. This page shows what that looks like in practice — the actual sequence of steps a real person walks through, start to finish, for the five journeys that make up Interwise’s core loop: a hiring manager fills a role, an applicant experiences the public side of that, a payroll manager runs a compliant payroll, a tenant admin sets the company up, and an employee lives in self-service day to day.

Hiring Manager

Hiring is done by a COMPANY_ADMIN (or a TENANT_ADMIN, who can act at any company) using the Hiring module. The loop starts with a job that doesn’t exist yet and ends with a new row in the employee directory — with nothing re-typed in between.

Create Job Post Role, department, comp Publish Goes live on careers page Applications Arrive Candidates apply directly Advance Pipeline Review, interview, offer Hire & Convert Becomes an employee

Create a job post. Title, department, location, employment type, and a description — saved as a draft, not yet visible to anyone outside the company.

Publish. Flipping the job to published puts it on the tenant’s public careers page immediately, with no separate deploy or delay.

Applications arrive. Candidates apply directly through the public form (see the Applicant journey below) — no email inbox to triage, no spreadsheet of resumes.

Review & advance through the pipeline. Each application moves through stages — new, reviewing, interview, offer — as the hiring manager evaluates it. Nothing is lost between stages; the full history stays on the application.

Make an offer, then hire. Once an application reaches offer and the candidate accepts, the hiring manager marks them hired.

Convert to employee. The application’s data — name, contact details, tax ID, bank account, expected start date — carries straight into a new employee record. Nothing gets re-keyed into a second system, and nothing gets lost in the handoff from recruiting to HR.

Applicant

This is the one part of Interwise that isn’t behind a login — a public candidate applies without an account, a password, or any Interwise-specific knowledge at all. Because it’s the only surface a candidate (and often, by extension, the company’s public reputation) ever touches, it’s held to the same bar as the rest of the product: fast, mobile-first, and honest about what happens after the click.

Find a Role Browse the careers page Apply One form, no account Received Confirmation, no login Track Status Check progress anytime

Find a role. The tenant’s careers page lists every published job — title, department, location, employment type — with no clutter and no dead links.

Apply. One form: name, contact details, and the basics a company actually needs to move a candidate forward. No account to create first.

Application received. A clear confirmation that the application went through — the applicant isn’t left wondering whether the click worked.

Track status. The candidate can check where their application stands without sending a follow-up email into a void.

The bar here is trust: a careers page is often a candidate’s first real interaction with the company, and a clunky or confusing one reflects on the company, not just the software. It gets the same polish as every other part of the product.

Payroll Manager

Payroll is run by a PAYROLL_ADMIN (or a COMPANY_ADMIN, who has payroll powers as part of full company admin). By the time a run starts, the compensation setup for every employee already exists — this journey is about turning that configuration into a correct, paid-out period.

Compensation Set Employees already configured Run Payroll Select the pay period Engine Computes Proration, OT, BPJS, PPh 21 Review & Approve Check exceptions, sign off Distribute Payslips + bank file out

Compensation is already configured. Every employee carries the compensation items (basic salary, allowances, deductions) that feed the calculation — set up once during onboarding, adjusted only when something actually changes.

Run payroll for the period. The payroll manager picks the period and starts the run. Attendance and overtime for that period are pulled in automatically.

The engine computes. Working ratio prorates every attendance-linked item, overtime is grouped by ISO week and multiplied per Indonesian labor rules, BPJS (Kesehatan + Ketenagakerjaan) is calculated per employee, and PPh 21 is computed — IdTer rate for a normal month, bracket-progressive settlement in December or an employee’s last month.

Review results & exceptions. Once the run completes, the payroll manager reviews it line by line before anything goes further — unusual amounts, missing attendance, unapproved overtime — the kind of thing that should never reach a payslip unnoticed.

Approve, generate, and distribute. With the run reviewed, the payroll manager moves it forward: Interwise generates a payslip per employee and a bank-ready disbursement file, so the numbers on the payslip and the numbers going to the bank can never drift apart.

Tenant Admin

A TENANT_ADMIN owns everything about a customer organization — every company under it, every user, every setting. This journey starts the moment a brand-new tenant is invited onto the platform.

Accept Invite Set password, first login Create Company First legal entity Invite Users Assign roles per company Configure Settings Minimum wage, service charge Oversee Across every company

Accept the invite & set a password. A SUPERADMIN invites the tenant; the invited admin lands on the same accept-invite flow every Interwise user goes through, and that first login attaches them as the tenant’s owner.

Create the first company. No company is auto-created during onboarding — a tenant and a company are different things. The tenant admin creates the first company themselves, which is also where tenant-wide configuration lives.

Invite users & assign roles. COMPANY_ADMIN, PAYROLL_ADMIN, VIEWER, and employee accounts all get added from here, each scoped to a specific company under the tenant.

Configure company settings. Minimum wage (province and city) and the service charge model the payroll engine checks a run against. Tax and BPJS configuration itself lives per employee, set as each person is added.

Oversee across companies. For a holding group running several legal entities, the tenant admin is the one role that sees all of them at once — everyone else is pinned to a single company.

Employee

Once onboarded — whether through direct invite or converted from a hired applicant — an employee’s day-to-day relationship with Interwise is entirely self-service, scoped to /me/* and nothing else.

Accept Invite Set password, first login View Payslips Every past period Check Attendance Clock records, hours Request Leave Submit for approval Leave Balance Days remaining

Accept the invite & set a password. The same accept-invite flow every role starts from — whether the employee was invited directly or arrived by being converted from a hired applicant.

View payslips. Every past pay period, with a real breakdown of earnings, deductions, and take-home pay — not just a final number.

Check attendance. Clock records and hours worked for the period, the same data the payroll engine uses to prorate pay.

Request leave. Submit a leave request for approval, without emailing HR or filling out a paper form.

View leave balance. How many days remain, so a leave request is an informed decision, not a guess.

Nothing here reaches beyond the employee’s own record — no visibility into coworkers’ pay, attendance, or leave. That boundary is enforced the same way tenant isolation is: at the data layer, not just in what the interface happens to show.

Where to Go Next

  • Overview — what Interwise is, the modules it’s built from, and the core loop from hiring a candidate to a compliant payslip.
  • Roles & Access — the full role model and how tenant isolation keeps every customer’s data separate.

Deep dives on the Hiring/ATS pipeline and the payroll calculation engine — covering each in the same detail as this page covers the roles — are on the way.