Back to Featured Work
ProjectView UI

CRM Publishing Portal

A separate Laravel + Lighthouse GraphQL service behind an internal publishing portal: the team writes release notes and tracks customer feature requests in one app, and the published notes surface to every tenant inside the HRMS product itself.

View Portfolio Section
Problem

Product updates and customer requests were scattered, so tenants did not reliably learn what shipped and requests had no tracked state.

  • Release announcements had no single authoring surface or consistent format
  • Customer feature requests arrived through ad-hoc channels with no status anyone could check
  • Whatever the team published had to reach tenants inside the product, not in a separate place they would never visit
Architecture

A standalone GraphQL API for the internal portal, deliberately kept separate from the main HRMS backend, whose published content is consumed by the product.

  • Laravel with Lighthouse exposing a small, focused schema rather than extending the main HRMS API
  • Two domains only - release notes and feature requests - each with create, update, and delete plus filtered pagination
  • JWT auth with a Microsoft login path, so internal staff sign in with existing company accounts
  • S3-backed file uploads for the images embedded in release note content
Implementation

A rich-text authoring portal on one side, and in-product delivery to tenants on the other.

  • Release notes are tagged as new feature, improvement, bug fix, or security enhancement, and filterable by tag and title
  • Feature requests carry a status lifecycle - in review, accepted, started working, released, non-priority - plus the domains that requested them
  • Authored content is HTML-sanitized before storage, since it is written rich-text and rendered inside the product
  • Published notes appear to tenants as an in-app release note modal, with a feature request panel on the dashboard
Impact

Gave the team one place to publish and one place to track demand, with tenants seeing updates where they already work.

  • Release communication became consistent and tagged instead of ad-hoc
  • Feature requests gained a visible status trail from request through release
  • Keeping the service separate let the portal evolve without adding surface area to the main HRMS API