IxDF Developer Docs

Appearance

JobBoard module overview ​

At IxDF members not only acquire design skills but also get matched with relevant jobs in the design industry.

Overview ​

The system includes:

  • Dual-mode Job Postings (different for guests vs. members)
  • Job Posting approval workflow
  • Job matching engine
  • Integration with Local Groups
  • Hiring Partner network
  • Automated job scraping from external sources

Job Posting Status ​

  • draft: Initially the member (or paying guest) creates a job posting as a draft, the job posting can be previewed before submitting it.
  • pending_enrichment: Once a member is happy with the job posting and clicks "Save and Submit for Approval" button, the job posting transitions to the pending_enrichment state. For paying guests there are intermediary steps, because they need to make a payment. All job postings which are pending enrichment are processed in the background by AI. Once they are enriched they are ready to be reviewed by the mex team.
  • pending_approval: At this stage the job posting is already AI enriched and ready to be reviewed by the mex team. The mex team can find all job postings in this state by filtering the list of job postings in the admin panel. They either approve or reject a job posting. They can provide a reason for rejection.
  • approved: In this state the job posting becomes visible on the platform.
  • expired: After 3 months the job posting automatically expires. It is also possible for a job posting to expire earlier, because the member can mark the position as filled or no longer relevant. Whenever a job posting transitions to the expired state, we store the reason for expiration (e.g. "Position filled").
  • rejected: When a job posting is rejected, the member (or paying guest) is notified. The notification contains an explanation that the job was removed, optional reason if the admin provides one, contact or support link if clarification is required.

Notes:

  • Until a job posting is approved, members (or paying guests) have an ability to modify it.
  • A job posting will never transition from rejected state back to the draft state for further editing.
  • In rare cases, it is possible for a paid job posting to be rejected, the mex team will handle this edge case.
  • Presentation logic must ensure that only postings with a approved status appear on the platform.

Job Posting Pricing ​

Job postings have different pricing based on who creates them:

  • Members: Job postings are free for IxDF members.
  • Paying Guests: Job postings are paid. The price is configured in config/ixdf_job_board.php under job_posting_unit_amount_in_usd.

Status Flow by User Type ​

For Members:

  1. Member creates a job posting (draft)
  2. Member submits the job posting
  3. Status transitions immediately to pending_enrichment

For Paying Guests:

  1. Guest creates a job posting (draft)
  2. Guest proceeds to payment
  3. After successful payment, JobPostingOrderFulfiller transitions status to pending_enrichment

In both cases, once enrichment is complete, the status automatically transitions to pending_approval for review by the mex team.

Job Posting Timestamps ​

  • Created At — created_at is set automatically. The record only contains the raw payload supplied by the ingestion API.
  • Published At — published_at marks the time at which the job posting was published on the original platform for scraped job postings, or IxDF for locally sourced job postings.
  • Expire At — expire_at marks when the posting should no longer be surfaced. Once populated (either manually or via automation) the record is treated as inactive even if it was previously approved. expiration_reason captures the rationale behind the expiry.

Job Posting Access Restrictions ​

Jobs functionality is accessible to:

  • guests
  • individual members
  • team members whose team has jobs_enabled flag set to true
  • admins

Jobs functionality is not accessible to team members whose team has jobs_enabled set to false (the default). Team members access IxDF through their employer's company membership and are not the target audience for job postings. We don't want to incentivize them to look for job opportunities outside their current employment.

The access permissions are enforced by JobPostingPolicy.

Additionally, there is a monthly limit of job postings that can be created by members, to prevent spam:

php
config('ixdf_job_board.max_job_postings_per_month')

Job Posting Reports ​

Members and guests can flag any job posting that looks suspicious or outdated. Each flag is persisted in job_board__job_posting_reports (represented by App\Modules\JobBoard\Models\JobPostingReport). The record stores the job posting (job_posting_id), the chosen reason, a required description, and reviewer metadata (reviewer_member_id, reviewed_at, review).

For member reports, the reporter is identified by reporter_member_id. For guest reports, reporter_member_id is null and the guest's contact info is stored in guest_name and guest_email. Guest submissions are protected by Cloudflare Turnstile.

Reasons are stored as the JobPostingReportReason enum and currently include:

  • outdated
  • duplicate
  • violates_policy
  • unrelated
  • filled
  • other

Reports must be explicitly reviewed by the Member Experience team; nothing auto-resolves.

Skills ​

Skills represent specific competencies and expertise areas in the design field that can be associated with both job postings and courses. This creates a connection between what skills are taught in courses and what skills are required for jobs.

Key characteristics:

  • Examples: User Research, Prototyping, Figma, Interaction Design, Visual Design
  • Can be associated with Job Postings to indicate required or preferred skills
  • Can be associated with Courses to indicate what skills the course teaches
  • Uses a polymorphic relationship through the job_board__skilled_objects pivot table
  • Helps the job matching engine connect members with relevant job opportunities based on skills they've learned

Perks ​

Perks represent benefits and incentives that employers offer as part of their job postings. They help attract candidates by highlighting the additional value beyond salary.

Key characteristics:

  • Examples: Health Insurance, Remote Work, Flexible Hours, Paid Time Off, Professional Development Budget
  • Associated exclusively with Job Postings
  • Uses a standard many-to-many relationship through the job_board__job_posting_perk pivot table

The job search functionality is implemented in JobSearchService and supports the following features:

Full-text search:

Uses MySQL's MATCH AGAINST in boolean mode to search job titles and descriptions. Each search term is treated as a prefix match (e.g., "design" matches "designer", "designing").

Filters:

  • Location
    • By country name (exact match)
    • By coordinates within a 150km radius when geocoded location is provided
  • Employment type (full-time, part-time, etc.)
  • Location type (remote, on-site, etc.)
  • IxDF Community: "My Communities" shows jobs within 150km of the member's local groups (up to 5 groups)

Access control:

Guests search against markdown_redacted_description while members search the full markdown_description.

Results are ordered by featured status first, then by publication date (newest first).

API ​

See docs/domain/job-board/API.md for authentication setup and the list of public endpoints.