Final business-approved workflow record. Use this worksheet to review or amend individual rules; implementation planning and backend enforcement are separate next steps.
59 of 59 reviewed · 59 approved · 0 need changes · 0 updated rules need your decisionSaved in this browser
1. Roles and permissions
R1 — Admin authority
Admin may view/manage jobs, hubs, referrals, payouts, accounts, requests, notifications, and audit records; manage jobs/hubs and Hub Editor accounts; decide requests; publish; verify milestones; decide payouts; and change global settings.
R2 — Admin safeguards and conflicts
Only Admin may approve requests; sensitive actions must be audited. Do not investigate family relationships or require proof of kinship. Admins disclose conflicts they already know about and recuse when an uninvolved Admin is available. A sole Admin may decide a disclosed conflict case by recording the conflict note and ordinary referral/application evidence and the decision in the audit log. Family status alone is not evidence of fraud.
R3 — Hub Editor access
Hub Editors may view all jobs/hubs and create or edit drafts, including proposed active/inactive status changes; mark hub addresses verified in drafts; submit additions/edits for Admin review and job/hub deletion requests; and view relevant guidance, notifications, request status, and only their own activity.
R4 — Hub Editor restrictions
Hub Editors cannot manage accounts, directly delete records, approve/reject requests (including their own), apply drafts to live data, publish live files, access referrals/payouts/generated referral files, or change global settings. Additions, edits, proposed status changes, and deletion requests appear in a dedicated Admin-only tab/change tracker for review; each submission preserves its reviewed revision. Admin receives an in-app notification with the requester, affected records/change count, and a link to the tracker.
R5 — Referrer access
Referrers may submit candidate referrals after confirming consent; view only their own referrals, status, payout history/destination, profile and assistance information; update their own profile/payout destination subject to validation; and accept or decline remote assistance.
R6 — Referrer restrictions
Referrers cannot view other referrers/candidates or administrative records, edit verification/outcome/milestone/payout fields, approve payouts, publish, delete, forward candidates, or create staff accounts.
R7 — Permission matrix consistency
Confirm the permission matrix agrees with the detailed role descriptions, including job/hub access, publication, account management, referral submission, milestone verification, profile updates, audit visibility, and global settings.
2. Job and hub rules
R8 — Job publication required fields
A publishable job needs title, partner, position, work type, salary, account type, and status. Incomplete records may be saved as drafts but not published.
R9 — Job-to-hub relationship
A job must have exactly one active hiring hub, and the hub must belong to the selected partner.
R10 — Work-type compatibility
Work at Home requires a remote hub; On-site requires an on-site hub; Hybrid requires a defined hybrid policy before publication.
R11 — Job content and Concentrix experience controls
A job needs a role overview, minimum education, experience requirement, and at least one job-specific qualification. For Concentrix, use linked experience-type and BPO-duration controls. Experience type distinguishes no work experience, non-BPO experience only, local BPO, international BPO, or both BPO and non-BPO. When BPO applies, select duration as under 6, 6 to under 12, 12 to under 24, 24 to under 36, or 36 months and above. Non-BPO experience does not count toward BPO duration.
R12 — On-site hub publication requirements
An on-site hub needs a partner, hub name, street/building address, city, any required recruitment days/hours, and a verification date no older than 90 days.
R13 — Remote hub requirements
A remote hub must be explicitly marked remote. Address fields display N/A — remote by default, are stored as not applicable/null (not as literal address text), and are excluded from remote-hub validation.
R14 — Deletion request workflow
Hub Editor submits a deletion request with a required reason. The record remains unchanged while pending or revision requested. Admin is notified in-app and may approve, reject, or request revisions/more information; rejection and revision requests require a note. The Editor is notified and may update and resubmit; every step is audited.
R15 — Deletion effects and request states
On approval, deletion safely updates dependent data: remove a deleted hub from linked draft jobs and unpublish or block an active published job that would have no valid hub. Request states are pending, revision_requested, approved, rejected, or cancelled; resubmission after revision returns to pending with a new revision reference.
3. Publication approval workflow
R16 — Admin direct publication
Admin may publish directly after validation. Create a versioned snapshot, publication audit event (user, timestamp, version, summary), and success/failure notification.
R17 — Hub Editor publication request
The change tracker groups proposed additions, edits, active/inactive changes, and deletion requests by submission and shows record type/ID, editor, time, change type, and readable before/after values. Submitted revisions are immutable so later draft edits cannot alter what Admin reviews. Submission stores requester, timestamp, affected IDs, revision snapshot/reference, and optional note; Admin receives an in-app notification naming the requester, affected records/change count, and linking to review.
R18 — Publication decision and states
Admin reviews the complete change set and chooses Approve and publish, Request revisions, or Reject. Revisions and rejection require an Admin note; the Editor receives an in-app decision notification. Approval publishes only the reviewed revision and creates a versioned snapshot; later draft edits are not included. Only Admin approval writes live careers files. States are pending, revision_requested, approved, rejected, cancelled, and published; resubmission creates a new review revision.
4. Referral lifecycle and payout milestones
R19 — Referral submission and consent
Submission requires date referred, candidate full name, active target job, and a matching careers-website application. Store application timestamp, candidate details, target partner/job, and form version. No matching application or disputed/false consent makes the referral invalid or fraud-suspected and ineligible.
R20 — Backend-controlled initial values
On submission, status is submitted; jobOffer is pending; start date is blank; Day 30/90/180 are pending; payout is not yet approved. Referrer cannot submit or modify protected verification or payout fields, including by altering a browser request.
R21 — Referral and milestone states
Referral states: submitted, processing, active, resigned, failed, withdrawn, invalid, fraud_suspected, closed. Milestones: pending, approved, forfeited, failed. Only Admin changes outcomes and milestone states.
R22 — Configured milestone amounts
Final passed application outcome: ₱200; failed/declined outcome: ₱100 subject to monthly limit; official first day attended: ₱300; Day 30: ₱500; Day 90 and Day 180: ₱0 monitoring only. Admin verifies each.
R23 — Payout cap and approval
Only approved milestones count. Maximum co-referrer payout for one referral is ₱1,000: ₱200 passed outcome, ₱300 first day, and ₱500 Day 30. Passed outcome has no monthly Referrer limit.
R24 — Failed/declined monthly limit
A verified Referrer identity may receive the ₱100 failed/declined incentive for only the first three eligible referrals per calendar month in Asia/Manila. Ranks 1–3 may qualify; rank 4 onward is ineligible with ₱0. Count resets monthly; reversal/reclassification requires recalculation and audit.
R25 — Candidate outcome limit across partners
Across partner applications in a rolling 180 days, approved outcome payout cannot exceed ₱200. A prior approved ₱100 failure allows at most a ₱100 passed-outcome top-up; a prior approved ₱200 passed outcome bars another outcome payout. A prior unpaid failure due only to the Referrer monthly limit does not reduce a later passed payout.
R26 — Repeat failed outcomes
A candidate can receive a failed/declined ₱100 incentive only once in a rolling 180-day period. A previous final failure blocks a later failure incentive even if the first incentive was not approved. Withdrawals before final decision earn ₱0 and do not consume a slot; resignation is not eligible.
R27 — Outcome eligibility evidence
Eligible failed/declined referrals require a matching careers application, genuine partner hiring process and final decision, Admin-marked failed/declined status, recorded decision date, ownership by the Referrer, correct Manila calendar month, and no disqualifying fake/duplicate/invalid/non-consenting/prior-active/former-employee status.
R28 — First day and Day 30 verification
First-day payout requires verified official start date and confirmation of attendance. Day 30 requires valid official start date and verified completion. If candidate passes but does not attend, only approved ₱200 outcome payout is earned and first-day/Day-30 milestones are forfeited.
R29 — Day 90/180 monitoring and partner commission timing
Day 90 and Day 180 dates are calculated from official start date and retained for monitoring only at ₱0. Partner commission waiting periods do not delay or alter co-referrer payouts through Day 30; OFFICE-GENIUS accepts that commercial risk.
R30 — Resignation, failure, and approved payouts
When resigned, unearned future milestones are forfeited. When failed, future milestones are forfeited after final decision. Existing approved payouts are not silently removed; changes require an Admin action and audit event.
5. Eligibility and anti-abuse controls
R31 — Prior application / recruitment
The Careers page application asks candidates whether they applied to or were actively recruited by the target partner in the previous 180 days. A qualifying prior application/recruitment makes the referral ineligible (ineligible_prior_application), except with written partner confirmation, Admin decision, reason, and audit event.
R32 — Former employees
Former employees of the target partner are payout-ineligible (ineligible_former_employee), except with written partner confirmation, Admin decision, reason, and audit event.
R33 — Duplicate ownership and new cycle
Referral credit is partner-specific. The referral date entered in the Referrers portal starts a 30-calendar-day window. For a claim to be valid, the candidate’s successful Careers application and the Referrer’s portal entry must both be recorded for the same partner within that window. If no Referrer makes a matching claim within 30 days, the application is attributed to OFFICE-GENIUS as a direct referral. If another Referrer enters an existing candidate whose application is recorded for a different partner, tell them which partner is already on file and ask whether they want to claim the candidate. If they do, they must first request an update to the recorded partner and position. If the candidate applies through the Careers page to a different partner, a Referrer may claim that partner-specific referral by recording it in the portal within 30 days of the referral date.
R34 — Cross-partner candidate history
Backend maintains protected candidate identity/outcome history across partners and enforces rolling-180-day outcome cap: later pass after an approved ₱100 failure receives at most ₱100 top-up; later genuine applications may still earn verified first-day and Day-30 payouts.
R35 — Unpaid failure and later outcomes
A candidate’s prior final failure blocks another failure incentive in the rolling period even if unpaid due to the monthly limit. That unpaid failure does not block a later passed ₱200 outcome; an approved ₱100 failure limits the pass to a ₱100 top-up.
R36 — Self, family, and household referrals
Self-referrals are prohibited. Family/household referrals are allowed without mandatory relationship disclosure when candidate applies through the website and genuinely undergoes hiring, subject to normal fraud checks.
R37 — Fraud response
Fake candidates, false information, false consent/application records, and other fraud may be invalid or fraud_suspected. Unapproved payouts are forfeited; account may be suspended; Admin records evidence and reason in audit log.
R38 — One identity and shared payout destination
One verified person may have one active Referrer account. Monthly limits are per verified identity, not account. Shared wallets/bank accounts are allowed but flagged for review.
6. Candidate and Referrer payout histories
R39 — Admin candidate-level history
Maintain protected candidate-level payout history across all applications, accessible only to Admin, and use it to enforce rolling 180-day cross-partner outcome rules.
R40 — Admin history contents
Show candidate name and protected identity reference; outcome-cap summary; chronological episodes with referral ID, dates, Referrer, partner/job, status/outcome, start date or non-sensitive reason unavailable; every milestone, amount/state, approval date, and payout/audit reference.
R41 — Separate payout and monitoring entries
Show outcome, first-day, Day-30, Day-90, and Day-180 separately. Outcome is ₱200 or an eligible ₱100 top-up / ₱100 failure; first day ₱300; Day 30 ₱500; Day 90/180 ₱0 monitoring only. Clearly state when the candidate’s rolling-period ₱200 outcome maximum is reached.
R42 — Referrer private milestone history
Each Referrer sees only their own referrals: ID, candidate, target partner/job, referred date, status/outcome, available start date, milestone states/amounts, approved total, and meaningful non-sensitive reasons for pending/forfeited/failed/ineligible items.
R43 — Cross-referrer privacy
Referrer must never see another Referrer, referral, payout, or candidate-level cross-partner history. If cross-partner rules affect eligibility, show only a neutral explanation such as ‘Outcome payout adjusted under candidate eligibility rules’.
R44 — History example and rolling window
Confirm the example policy: approved ₱100 failure followed by a later pass within 180 days results in a ₱100 top-up, with separately eligible first-day/Day-30 payouts and a clear cap-reached message.
7. Candidate forwarding / portability
R45 — Forwarding prerequisites
Forward only with explicit portability consent, an Admin-recorded qualifying outcome, an Admin-selected destination partner, and a system log of data forwarded, recipient, and timestamp.
R46 — Referrer attribution and forwarding
Referral credit is specific to the partner selected in the candidate’s successful Careers application. The referral date recorded in the Referrers portal starts a 30-calendar-day claim window; the portal entry and matching Careers application must both be on record for the same partner within that window. If no matching claim is recorded within 30 days, the application is attributed to OFFICE-GENIUS as a direct referral. If a Referrer enters an existing candidate whose recorded application is for another partner, tell the Referrer which partner is already on file and ask whether they want to claim the candidate. If they do, they must first request an update to the recorded partner and position. A candidate who applies through Careers to a different partner may be claimed for that partner when the Referrer records the referral within 30 days. Application consent does not authorize data forwarding; only Admin may forward under the portability rules.
8. Notifications
R47 — Required recipients and notification details
Admin receives in-app alerts for deletion requests (requester, record, reason, tracker link) and publication/change requests (requester, affected records/change count, review link). Requesting Editors receive deletion/publication decisions, required notes, affected revision, and publication version when applicable. Admin receives referral-submitted alerts (Referrer, candidate, job, consent), failed-incentive-limit alerts (Referrer, month, referral), and stale-hub-verification alerts (hub, age; also relevant Editor). The owning Referrer receives status/milestone updates with non-sensitive explanations and payout approvals with amount/status.
R48 — Notification delivery and privacy
In-app notification is source of truth; later email failures must not lose it. Notifications must not disclose another Referrer’s candidate/payout data. Each notification has created/read and optionally archived states.
9. Audit log and retention
R49 — Required audit event fields
Immutable event includes event ID, UTC timestamp and display timezone, authenticated user ID/role, action, affected record type/ID, before/after values where practical, related request/approval IDs, and required reason/note.
R50 — Actions that must be audited
Account/role changes, job/hub changes, request decisions, publication, referral verification, payout decisions, forwarding, and profile/payout-destination changes are sensitive actions and must be logged.
R51 — Retention
Audit logs, referral records, and payout records are retained for 7 years after closure or final payment, unless longer legal, tax, or dispute requirements apply.
R52 — Payout reversals and recovery
Approved payouts are never silently removed. Reversal/adjustment requires Admin action, evidence, reason, and audit event. Recovery is limited to fraud, duplicate referral, material error, or false information—not ordinary resignation after a correct approval.
R53 — Second Admin approval safeguards
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 bulk payout batches exceeding ₱1,000 or 5 referrals. Do not require routine relationship investigations or kinship evidence.
A sole Admin may publish directly. A second Admin is required for the safeguards specified in the audit section.
R56 — Candidate forwarding source
Forwarding uses the destination company’s form, with careers-website application profile as the reference source; consent and forwarding log still apply.
R57 — Hub Editor scope
Hub Editors can view and edit all jobs and hubs, subject to role restrictions.
R58 — Timezone and rolling-window interpretation
Confirm Asia/Manila for monthly eligibility. Confirm how exact rolling 180-day boundaries and calendar dates are interpreted consistently by the business and backend.
R59 — Legal, privacy, and operational review
Confirm appropriate review of candidate consent, sensitive identity/payout data, account security, and retention obligations before implementation; this worksheet is not legal approval.
Final review and sign-off
Complete this after reviewing the individual rules. Selecting “Approved” is your confirmation that the reviewed workflow is accepted as the business rulebook, subject to any remarks recorded above.