# Refer2Earn — Phase 1 Workflow & Permission Specification **Status:** Business approval recorded; ready for backend implementation planning **Scope:** Referral portal roles, approvals, payout milestones, publication, deletion, and notifications. **Approval record:** Emmanuel Habana — 2026-09-30 — Approved (“Implement it”). This records business approval of the workflow, not legal/privacy approval or completion of implementation. > This document defines the business rules the backend must enforce. A hidden button, a disabled input, or a role-specific screen is not security; every rule below must be validated server-side once authentication and persistent storage are added. --- ## 1. Roles ### 1.1 Admin The Admin is the system owner and final approver. The Admin can: - View and manage all jobs, hubs, referrals, payouts, accounts, requests, notifications, and audit records. - Create, edit, deactivate, and delete jobs and hubs. - Create and manage Hub Editor accounts. - Approve or reject deletion requests and publication requests. - Publish approved jobs and hubs to the live careers data files. - Verify referral milestones and approve or forfeit payouts. - View and act on all notifications and audit records. - Change system-wide settings, publishing settings, and security settings. The Admin must not: - Approve a request using a non-Admin account. - Bypass the audit log for a sensitive action. An Admin may publish directly without a second Admin. For referral decisions, do not attempt to detect family relationships through intrusive checks or require proof of kinship. Admins must disclose a known family, household, personal, or financial conflict; do not conduct routine kinship checks or require proof of a relationship. If another uninvolved Admin is available, the involved Admin recuses and the uninvolved Admin reviews and decides the case. If the portal has only one Admin, that Admin may decide a disclosed or known conflict case only after recording a brief conflict note, the matching careers application, partner outcome evidence, and the decision in the audit log. Any credible fraud concern follows the fraud-investigation process; family status alone is not evidence of fraud. ### 1.2 Hub Editor A Hub Editor maintains job and hub information but does not control live publication or irreversible actions. The Hub Editor can: - View all jobs and hubs, assigned cleanup items, roles/permissions, their own profile, relevant notifications, security guidance, and change-request status. - Create and edit job and hub drafts, including proposed active/inactive status changes. - Mark a hub address as verified in a draft. - Submit a job/hub deletion request with a required reason. - Submit proposed additions and edits for Admin review through the change tracker. - View only their own activity and requests. The Hub Editor must not: - Create, edit, deactivate, delete, or reset user accounts. - Directly delete a job or hub. - Apply draft changes to live careers data or approve/reject change or deletion requests, including their own. - Publish live `jobs.json` or `hubs.json`. - Access referrals, referrer payout information, or generated referral files. - Change system-wide security, notification, publishing, or destructive settings. ### 1.3 Referrer A Referrer has a private workspace for their own candidate referrals and payout details. The Referrer can: - Create a candidate referral after confirming candidate submission consent. - View only referrals associated with their own referrer ID. - View only their own referral status, earned payout history, payout destination, profile, and assistance information. - Update their own payout destination/profile details, subject to validation. - Accept or decline an Admin remote-assistance request. The Referrer must not: - View other referrers, candidates, jobs administration, hubs administration, generated files, team accounts, audit records, or system settings. - Edit job-offer verification, start date, Day 30, Day 90, Day 180, referral outcome, payout status, or payout amount. - Approve payouts, publish files, delete records, forward a candidate, or create staff accounts. --- ## 2. Permission Matrix | Capability | Admin | Hub Editor | Referrer | |---|:---:|:---:|:---:| | View jobs and hubs | Yes | Yes | No administration access | | Create/edit jobs and hubs | Yes | Yes, as drafts | No | | Set job/hub active or inactive | Yes | Yes, as proposed draft changes | No | | Delete job/hub | Yes | Request only | No | | Approve/reject deletion request | Yes | No | No | | Submit publication request | Optional/direct publish | Yes | No | | Approve/reject publication request | Yes | No | No | | Publish live careers files | Yes | No | No | | Manage team accounts | Yes | No | No | | View all referrals/payouts | Yes | No | No | | Submit candidate referral | Yes | No | Own referrals only | | Verify JO/start/milestones | Yes | No | No | | Approve/forfeit payout | Yes | No | No | | View own referral/payout records | N/A | No | Yes | | Update own profile | Yes | Yes | Yes | | Update own payout destination | Yes | No | Yes | | View full audit log | Yes | No | No | | View own activity | Yes | Yes | Yes | | Change global settings | Yes | No | No | --- ## 3. Job and Hub Rules ### 3.1 Job validity before publication A job may be submitted for publication only when: 1. It has a title, partner, position, work type, salary, account type, and status. 2. It has exactly one active hiring hub. 3. The selected hub belongs to the selected partner. 4. The work type is compatible with the hub: - `Work at Home` requires a remote hub. - `On-site` requires an on-site hub. - `Hybrid` requires a defined hybrid policy before publication. 5. It contains a role overview, minimum education, experience requirement, and at least one job-specific qualification. 6. A Concentrix job follows the configured experience-segment rule. Use two linked controls rather than overlapping choices. The experience-type control distinguishes: no prior work experience; non-BPO work experience only; local BPO experience; BPO experience outside the local market; and both BPO and non-BPO experience. When BPO experience applies, require a separate, non-overlapping duration choice: under 6 months, 6 to under 12 months, 12 to under 24 months, 24 to under 36 months, or 36 months and above. Do not count non-BPO experience toward a BPO-duration requirement. A job may be saved as a draft while incomplete, but it must not be published. ### 3.2 Hub validity before publication An on-site hub may be published only when it has: - Partner - Hub name - Street/building address - City - Recruitment days/hours, if the business requires them - Verification date no older than 90 days A remote hub may omit address fields, but must explicitly be marked `remote`. In job/hub forms, show the address fields as `N/A — remote` by default for a remote selection; store the address values as not applicable/null rather than as a literal street address. Exclude those fields from remote-hub validation. ### 3.3 Deletion request workflow 1. Hub Editor selects **Request deletion** for a job or hub. 2. A reason is required. 3. The record remains available and unchanged while the request is pending. 4. Admin receives an in-app notification with a link to the change tracker. 5. In the tracker, Admin approves, rejects, or requests revisions/more information. Rejection and revision requests require a note; the Hub Editor is notified and may update and resubmit the request. The record remains unchanged while pending or revision requested. 6. On approval, the backend deletes the record and updates dependent data safely: - Deleting a hub removes it from linked draft jobs. - An active published job that would have no valid hub must be unpublished or blocked from publication. 7. Every step is written to the audit log. The request state is one of: `pending`, `revision_requested`, `approved`, `rejected`, `cancelled`. A resubmission after revisions returns the request to `pending` with a new revision reference. --- ## 4. Publication Approval Workflow ### 4.1 Admin publication An Admin may publish directly after validation. The system must create: - A versioned snapshot of published jobs and hubs. - A publication audit event with user, timestamp, version, and summary. - A success/failure notification. ### 4.2 Hub Editor change review and publication request 1. Hub Editor creates or edits drafts. Proposed additions, edits, active/inactive changes, and deletions do not alter live careers data. 2. The change tracker lists every proposed change in one review queue, grouped by request and showing record type/ID, editor, submission time, change type, and a readable before/after comparison. New records show proposed values; deletions show the record and required reason. Preserve each submitted revision so later draft edits cannot silently change what Admin reviewed. 3. Hub Editor selects **Submit for approval** and may add a request note. The backend validates the changed records and stores the requester, timestamp, affected IDs, before/after snapshot or immutable revision reference, and note. 4. On submission, Admin receives an in-app notification and a pending item in the change tracker. The notification identifies the requester, affected records/change count, and links to the review screen. Optional email may alert Admin but is not the source of truth. The tracker shows pending/revision status so Admin can see what still needs action. 5. Admin reviews the complete change set in the tracker and chooses **Approve and publish**, **Request revisions**, or **Reject**. Approval publishes only the reviewed revision and records a versioned snapshot. A request for revisions or rejection requires an Admin note; the Hub Editor receives an in-app notification with the decision and note. The editor may revise and resubmit; a resubmission creates a new review revision. 6. Only Admin approval may write the live careers files. Draft edits made after submission are not included in the approved revision. The request state is one of: `pending`, `revision_requested`, `approved`, `rejected`, `cancelled`, `published`. A resubmission after revisions returns the request to `pending` with a new revision reference. Deletion requests remain subject to the separate deletion workflow in Section 3.3, and their status and Admin decision are also visible in the same change tracker. --- ## 5. Referral Lifecycle ### 5.1 Referrer submission A Referrer submission must include: - Date referred - Candidate full name - Target active job - A matching candidate application submitted through the careers website Submitting the careers application is the candidate's recorded consent for OFFICE-GENIUS to process the application/referral for the selected partner. The backend must store the application timestamp, candidate details, target partner/job, and form version. A referrer must not claim consent for a candidate who has no matching careers-website application. A disputed, false, or mismatched application/consent record makes the referral `invalid` or `fraud_suspected` and ineligible for payout. At submission, backend-controlled fields must be set as follows: - `status`: `submitted` - `jobOffer`: `pending` - `startDate`: blank - `day30`, `day90`, `day180`: `pending` - `payout`: not yet approved The Referrer must not be able to submit or modify protected verification/payout fields, even by altering a browser request. ### 5.2 Admin verification states Referral record status: - `submitted` — referrer submitted; needs review. - `processing` — Admin is reviewing or partner processing is underway. - `active` — candidate started and remains active. - `resigned` — candidate left the role. - `failed` — candidate reached a final failed or declined partner decision. - `withdrawn` — candidate withdrew before a final partner decision. - `invalid` — the referral is ineligible or contains false/invalid information. - `fraud_suspected` — fraud or false consent/application information requires investigation. - `closed` — no further workflow is expected. Milestone states: - `pending` - `approved` - `forfeited` - `failed` Only the Admin can change a referral outcome or milestone state. ### 5.3 Payout milestones Initial configured scheme: | Milestone | Standard amount | Verification owner | |---|---:|---| | Final application outcome — passed | ₱200 | Admin | | Final application outcome — failed/declined | ₱100, subject to monthly limit | Admin | | Official first day attended | ₱300 | Admin | | 30th day completed | ₱500 | Admin | | 90th day | ₱0.00 — monitoring only | Admin | | 180th day | ₱0.00 — monitoring only | Admin | Rules: - A milestone payout is counted only after its state is `approved`. - The maximum co-referrer payout for one referral is **₱1,000.00**: ₱200.00 after a verified final passed outcome, ₱300.00 after verified official first-day attendance, and ₱500.00 after the 30th day is completed. - A passed outcome earns the ₱200.00 outcome payout with no monthly payout limit. - A failed or declined outcome may earn a ₱100.00 consolation incentive for the first three eligible failed/declined referrals for that verified Referrer identity in a calendar month. - A candidate who passes but does not attend their official first day earns only the approved ₱200.00 passed-outcome payout. The ₱300.00 and ₱500.00 milestones are forfeited. - Cross-partner outcome rule (rolling 180 days): a candidate's total approved outcome payout across all partner applications must not exceed ₱200. A passed outcome normally earns ₱200. If the candidate already has an approved ₱100 failed/declined outcome incentive in the preceding 180 days, a later verified passed outcome may receive only a ₱100 top-up, bringing the candidate's total outcome payout to ₱200. If the candidate already has an approved ₱200 passed-outcome payout, a later referral cannot receive another outcome payout. A genuine later referral may still qualify for the ₱300 official-first-day and ₱500 Day-30 milestones after normal verification. - A candidate may receive a failed/declined ₱100 outcome incentive only once in a rolling 180-day period. If the candidate has already reached a final failed/declined outcome during that period, any later failed or declined application is ineligible for another failed/declined incentive, regardless of Referrer, partner, or whether the first failed/declined incentive was approved. This prevents payment when a previously failed candidate fails or is declined again in a later partner hiring process or offer. - The official-first-day milestone requires a verified official start date and confirmation that the candidate attended their first day. - The 30th-day milestone requires a valid official start date and verified completion of Day 30. - The 90th and 180th day dates are calculated from the official start date and are retained for **monitoring only**. Their payout amount is permanently ₱0.00 under this scheme. - A partner may require OFFICE-GENIUS to wait until Day 90 or Day 180 before it receives its own commission. This does not change the co-referrer's approved payouts through Day 30; OFFICE-GENIUS accepts that commercial risk. - When the referral is marked `resigned`, all unearned future milestones become `forfeited`. - When the referral is marked `failed`, future milestones become `forfeited` after the failed/declined outcome decision. - Existing approved payouts are never silently removed; changes require an Admin action and audit event. ### 5.4 Failed/declined ₱100 policy **Confirmed rule:** A verified Referrer identity may receive a ₱100 consolation incentive for only the first **three eligible failed/declined referrals per calendar month**. A verified `passed` outcome earns its own ₱200 payout with no monthly limit, subject to the cross-partner 180-day payout restriction in Section 5.3. An eligible failed/declined referral must: - Have a matching application submitted through the careers website. - Have genuinely undergone the hiring process through the partner's final decision. - Be marked `failed` or `declined` by an Admin. - Have a recorded final-outcome decision date. - Belong to that Referrer. - Be within the same calendar month based on the configured portal timezone (`Asia/Manila`). - Not be fake, duplicate, invalid, non-consenting, a prior-active applicant, or an ineligible former-employee case. For each verified Referrer identity/month, for failed/declined outcomes only: - Eligibility ranks 1–3: `eligible`, and ₱100 may be approved by Admin for each qualifying referral. - Eligibility rank 4 onward: `ineligible_limit_reached`, and payout is ₱0. - The count resets automatically on the first day of the next calendar month. - Reversing or reclassifying an outcome requires recalculation and an audit event. For a verified passed outcome: - The result is `eligible_passed` for a ₱200 payout when the candidate has not received an approved outcome payout through any partner application in the preceding rolling 180 days. - If the candidate has an approved ₱100 failed/declined outcome incentive in the preceding rolling 180 days, the result is `eligible_passed_top_up`; the later verified passed outcome may receive a ₱100 payout only. This brings the candidate's total approved outcome payout in the rolling period to ₱200. - If the candidate already has an approved ₱200 passed-outcome payout in the preceding rolling 180 days, the later passed outcome is `ineligible_cross_partner_outcome_paid`; its verified ₱300 official-first-day and ₱500 Day-30 milestones may still be approved. - A passed outcome has no monthly Referrer limit. If the candidate previously had a failed/declined outcome during the preceding rolling 180 days but no ₱100 was approved because that Referrer had already used the monthly failed/declined limit, the candidate remains eligible for the full ₱200 passed-outcome payout. The earlier unpaid failure does not consume outcome-payout value. A withdrawal that does not reach the partner's final hiring decision is marked `withdrawn`, earns ₱0, and does not consume the monthly failed/declined slot. A resignation is not eligible for the ₱100 failed/declined consolation incentive. ### 5.5 Eligibility, duplicate ownership, and anti-abuse controls - A referral is ineligible when the candidate applied directly, was referred, or was already in the target partner's active recruitment process within the preceding 180 days. It is marked `ineligible_prior_application` and earns no payout. An exception requires written partner confirmation, an Admin decision, a reason, and an audit event. - A former employee of the target partner is ineligible for referral payouts and is marked `ineligible_former_employee`. An exception requires written partner confirmation, an Admin decision, a reason, and an audit event. - For duplicate referrals for the same candidate and target partner, the earliest valid referral owns the referral. A valid Referrer claim must be recorded within 30 calendar days of the referral date and have a matching careers-website application for that partner; this claim deadline is separate from the 180-day prior-application rule. The candidate must also not be a former employee. - The 180-day period applies to prior applications or active recruitment at the target partner, not to the Referrer's claim deadline. A new referral cycle to the same partner may become eligible after that prior-application period has passed, provided the candidate has no active prior application, submits a new application through the careers website, is not a former employee, and cannot receive duplicate payouts for the same recruitment cycle. - The backend must maintain a protected candidate identity and outcome history across partners. During a rolling 180-day period, the candidate's approved outcome payouts must not exceed ₱200: a passed outcome earns ₱200 when no earlier outcome payout was approved, while a later passed outcome after an approved ₱100 failed/declined incentive earns a ₱100 top-up only. A later genuine application remains recordable and may still qualify for verified ₱300 official-first-day and ₱500 Day-30 payouts. - A candidate who has already reached a failed/declined final outcome in the preceding rolling 180 days cannot receive a second failed/declined ₱100 incentive, even when no ₱100 was approved for the first failure because its Referrer had reached the monthly failed/declined limit. Any referrer is therefore ineligible for a failed/declined incentive if that candidate later fails or is declined by another partner in the rolling period. The earlier unpaid failure does not prevent a later verified passed outcome from receiving ₱200; an earlier approved ₱100 failure permits only a ₱100 passed-outcome top-up. - Self-referrals are prohibited. - Family and household referrals are allowed without mandatory relationship disclosure when the candidate applies through the website and genuinely undergoes the hiring process. They remain subject to normal fraud checks. - Fake candidates, false information, false application/consent records, or other fraud may be marked `invalid` or `fraud_suspected`. Unapproved payouts are forfeited, the account may be suspended, and the Admin must record evidence and a reason in the audit log. - One verified person may have only one active Referrer account. Monthly eligibility limits apply per verified identity, not per account. Shared payout wallets or bank accounts are allowed but must be flagged for review. ### 5.6 Candidate Payout History and Referrer Milestone History The backend must maintain a protected, candidate-level payout history across all referral and partner application records. This history is an Admin-only tracking view and is used to enforce the rolling 180-day cross-partner outcome-payout rules. For each candidate, the Admin history must show, in chronological order: - Candidate name and protected candidate identity reference. - A clear outcome-payout summary, including either `Outcome payout capacity available` or `Maximum ₱200.00 candidate outcome payout reached in the current rolling 180-day period`. - Each referral/application episode: referral ID, date referred, Referrer name/ID, target partner and job, referral status, final outcome, official start date or a non-sensitive reason it is unavailable, and the amount/status of every milestone. - Outcome payout, official-first-day payout, Day-30 payout, Day-90 monitoring state, and Day-180 monitoring state as separate entries. The configured amounts are ₱200.00 for a passed outcome (or a ₱100.00 top-up after an approved failed/declined ₱100.00 incentive), ₱100.00 for an eligible failed/declined outcome, ₱300.00 for verified official first-day attendance, and ₱500.00 for verified Day-30 completion. Day 90 and Day 180 remain ₱0.00 monitoring-only milestones. - Payout state (`pending`, `approved`, `forfeited`, `failed`, or `not_eligible`), approval date, and a reference to the payout/audit record where applicable. Example: a candidate referred to Partner A on 2026-07-29 may have an approved ₱100.00 failed/declined outcome incentive and no start-date or later-milestone payout. If genuinely re-referred to Partner B on 2026-09-15 and later passes, the candidate-level history must show a ₱100.00 passed-outcome top-up (not a second ₱200.00 outcome payout), followed by any separately verified ₱300.00 first-day and ₱500.00 Day-30 payouts. The history must then state that the ₱200.00 maximum candidate outcome payout has been reached for the applicable rolling 180-day period. Each Referrer’s private **My Referrals** workspace must provide a milestone tracker and payout history for only that Referrer’s own referrals. For every owned referral, it must show the referral ID, candidate name, target partner/job, date referred, current status, outcome, official start date where available, each milestone's state and amount, approved payout total, and meaningful non-sensitive explanations for pending, forfeited, failed, or ineligible milestones. A Referrer must never see another Referrer’s identity, referral, payout, or the candidate-level cross-partner history; where a cross-partner rule affects their referral, the portal may show only a neutral explanation such as `Outcome payout adjusted under candidate eligibility rules`. ### 5.7 Candidate forwarding / portability A candidate may be forwarded to another partner only when: 1. The candidate explicitly granted forwarding/portability consent. 2. The Admin records a qualifying outcome (for example, resigned or failed). 3. The Admin selects the destination partner. 4. The system logs which data was forwarded, to whom, and when. A Referrer cannot forward candidate data. --- ### 5.8 Referral attribution across partners A referral attribution is separate from forwarding candidate data: - A Referrer's claim for a candidate/partner is valid for 30 calendar days from the recorded referral date, provided the candidate submits a matching careers-website application for that partner within that window and the other eligibility rules are met. - A candidate may independently choose another partner and submit a new application. The same Referrer or a different Referrer may receive attribution for that separate partner application only when the candidate has a matching application and the referral claim satisfies the 30-day window. Existing prior-application, duplicate-ownership, consent, and payout-history rules still apply. - If a candidate applies directly without an already-recorded valid Referrer attribution, record the application as direct OFFICE-GENIUS attribution; a later Referrer claim cannot overwrite it. - Each careers application records the selected partner and its own consent/application timestamp. This consent does not authorize a Referrer to transfer or forward candidate data to another partner. Admin-only forwarding remains governed by Section 5.7. ## 6. Notifications ### 6.1 Required in-app notifications | Event | Recipient | Required content | |---|---|---| | Deletion request submitted | Admin | requester, record, reason, link to the change tracker | | Deletion request approved, revision requested, or rejected | Requesting Hub Editor | decision, required Admin note for revision/rejection, record, and link to the change tracker | | Publication/change request submitted | Admin | requester, affected records and change count, link to the change tracker review | | Publication/change request approved, revision requested, or rejected | Requesting Hub Editor | decision, Admin note, affected revision, and publication version if published | | Referral submitted | Admin | referrer, candidate, target job, consent confirmation | | Referral status/milestone updated | Owning Referrer | referral ID, changed status, non-sensitive explanation | | Payout approved | Owning Referrer | referral ID, amount, payout status | | Failed-incentive limit reached | Admin | referrer, month, affected referral | | Address verification is stale | Admin and relevant Hub Editor | hub, verification age | ### 6.2 Notification delivery rules - In-app notifications are the source of truth. - Email can be added later as a delivery channel, but email failure must not lose the in-app notification. - Notifications must not reveal another referrer’s candidate or payout data. - Each notification has `created`, `read`, and optionally `archived` states. --- ## 7. Audit Log Requirements Every sensitive action must create an immutable audit event with: - Event ID - Timestamp in UTC and display timezone - Authenticated user ID and role - Action name - Affected record type and ID - Before/after values where practical - Request/approval IDs where applicable - Reason or note for deletion, rejection, payout override, or forwarding Sensitive actions include account changes, role changes, job/hub changes, request decisions, publication, referral verification, payout decisions, forwarding, and profile/payout-destination changes. Audit logs, referral records, and payout records must be retained for **7 years** after closure or final payment, unless a longer legal, tax, or dispute requirement applies. A payout reversal or adjustment must never silently remove an approved payout. It requires an Admin action, evidence, reason, and an audit event. Recovery is permitted only for fraud, duplicate referral, material error, or false information—not ordinary resignation after a correctly approved milestone. A second Admin approval is required for manual payout overrides, duplicate/prior-application exceptions, fraud decisions, known or disclosed Admin/staff personal-conflict referrals when an uninvolved second Admin is available, and a bulk payout batch exceeding **₱1,000** or **5 referrals**. Do not require relationship investigations or kinship evidence as a routine control. --- ## 8. Acceptance Checklist Before Phase 2 Phase 1 is complete when the business owner confirms each point below: - [yes] Admin is the only role that can publish, approve requests, verify milestones, and approve payouts. - [yes] Hub Editor may edit jobs/hubs but can only request deletion and publication approval. - [yes] Referrer has access only to their own private referral/payout workspace. - [yes] Referrers cannot publish `jobs.json`, access generated files, or alter verification/payout fields. - [yes] The job/hub publication validation rules are accepted. - [yes] The deletion-request and publication-request state flows are accepted. - [yes] The referral status and milestone definitions are accepted. - [yes] The ₱100 failed/declined policy is confirmed, including the three-per-month limit and that resignation is ineligible. - [yes] Candidate forwarding consent rules are accepted. - [yes] Required notifications are accepted. - [yes] Candidate-level Admin payout history and private Referrer milestone/payout history are required. - [yes] Audit-log fields and retention expectations are accepted. --- ## 9. Confirmed operational settings - A sole Admin may publish directly. A second Admin is required for the safeguards listed in Section 7. - Audit logs, referral records, and payout records are retained for **7 years** after closure or final payment, unless a longer legal, tax, or dispute requirement applies. - Candidate forwarding uses the destination company’s form, with the careers-website application profile as the reference source. Consent and forwarding-log requirements in Section 5.7 still apply. - Hub Editors can view and edit all jobs and hubs, subject to their role restrictions.