Nexus · version 1.0

HR, CRM & project management

One back office for the people, the pipeline and the projects. Employees, attendance, leave and payroll; leads, deals, quotes, invoices and tickets; projects, tasks, sprints and time. This guide covers installing it and running it.

Welcome

Nexus is one system for one company. It runs three modules over a single set of people: HR, CRM & Sales, and Projects. There is no separate "employee" record — the person who books leave is the same row as the person who owns a deal and the person assigned a task, so a name means the same thing everywhere and nothing has to be kept in step by hand.

What is in the box

How to read this guide

Sections follow the order you will actually need them: install it, set the company up, then each module in the order the sidebar lists it. Every screen named here exists in the product — where something is deliberately absent it is listed under Deliberately not here rather than described as if it were built.

The shape of every screen

Lists work the same way throughout: a filter bar at the top of the card, a table, and paging at the bottom. Filters apply as you change them; there is no Search button to hunt for. Record pages open with a header — the name, a few facts, the buttons that change its state — and then tabs. Almost every record takes comments and file attachments at the bottom, so the discussion about an invoice lives on the invoice.

Server requirements

Nexus runs on ordinary shared hosting. There is nothing to compile, no Node on the server, no Redis, no websockets, no Supervisor, and nothing to put in crontab.

What you do not need

No cron job. No queue worker. No Node or npm on the server — the compiled CSS and JavaScript ship inside the ZIP in public/build/. Emails are sent inline as things happen, recurring invoices are issued by a button, and nothing anywhere waits on a background process. That is a deliberate constraint: a product that needs a worker is a product a shared host cannot run.

Uploads land in public/uploads/ rather than behind a storage symlink, because the symlink is the first thing a shared host breaks.

Installing

Nexus installs itself in a browser. You do not need shell access, phpMyAdmin or a command line.

1. Upload and unzip

   Put the contents of the ZIP on your server and point the domain at the public/ folder. Everything is included — you do not need to run composer install.

2. Open your domain

   Every address on the site redirects to /setup until the install is finished. You land on the requirements check.

3. Requirements

   Every required row must be green — the PHP version, the twelve extensions and the six writable paths. If one is not, enable the extension or fix the permission on the server and press Re-check. Nothing has been written yet.

4. Company

   The company name, currency and timezone, plus the environment and the site URL. The currency decides how every amount in the system is displayed; the timezone decides which day an evening clock-out belongs to. An application key is generated for you — roll it here if you like, but not once there is data. Leave Debug mode off on a live server.

5. Database

   Host, port, database name, username and password. Press Test connection before continuing. If the database does not exist, Nexus creates it — as long as your database user may. Leave Drop existing tables off unless you are re-installing over a failed attempt.

6. Administrator

   Your name, email and password. This account gets the admin role, which bypasses every permission check.

   Leave Install sample data off for a real company. It fills the system with a twelve-person demo team, a pipeline of deals, invoices, tickets and projects — useful for a look around, a lot to delete afterwards.

7. Review and install

   Check the summary, then press Install now. This writes .env, creates the tables, seeds the reference data and creates your account. It usually takes well under a minute; the log narrates each step and stops exactly where a failure happened.

Nothing is written until the last step. The wizard keeps your answers in the session, so an abandoned install can never leave a deployment with a rewritten .env pointing at a database that was never migrated.

If the install fails

The log on screen stops at the step that failed and shows the reason. Nothing after that point was changed. The usual causes:

Your first hour

A fresh install already knows the shape of a company — it has a default location, the standard leave types, a sales pipeline and a set of task statuses. This is the shortest route from there to a company that works.

1. Check the company details

   Settings → General Settings. The installer set the name, currency and timezone from what you typed. Add your logo, the legal name and address that print on invoices, and confirm the date format and which day your week starts on.

2. Set your working time

   Settings → HR Settings → Working time. Which days are working days, when the day starts and ends, how many minutes of grace before somebody is late, and the overtime multiplier. Nearly every calculation in the HR module reads these: what a leave day costs, what a timesheet is measured against, what a day of pay is worth.

3. Add your locations

   Settings → Locations. One is enough, but holidays are set per location, so a second office in another country needs its own row.

4. Build the org structure

   People → Departments, then Designations. Departments are the tree the org chart draws; designations are job titles. Both are short lists you will edit twice a year.

5. Add your people

   People → Employees. Each person gets a role, a department, a designation, a manager and a hire date. The role sets a starting set of permissions; the manager is who approves their leave and their timesheets. An employee code is generated for you.

6. Check the leave types

   Time & attendance → Leave Types. The install ships a sensible set. Set the days per year, whether it is paid, whether it accrues monthly or lands whole at the start of the year, and how much may be carried over.

7. Load this year's holidays

   Time & attendance → Holidays. Public holidays per location. Leave, timesheets, payroll and the workload chart all skip them.

8. Point email at your own server

   Settings → Notifications. Set the SMTP details and the from address, press Send test email, then choose which of the ten events raise an email as well as the bell.

9. Then open whichever module you bought it for

   Sales? Settings → CRM Settings to shape the pipeline, then start entering leads. Delivery? Settings → Project Settings for your board columns, then create a project. Neither needs the other.

Command-line install

If you have shell access and would rather not use the wizard:

composer install --no-dev --optimize-autoloader
cp .env.example .env
php artisan key:generate

# edit .env: APP_URL, APP_TIMEZONE and the DB_ settings

php artisan migrate --seed          # tables, default location, org structure, admin account
php artisan db:seed --class=DemoSeeder   # optional: the twelve-person demo company

npm install && npm run build       # only if you changed the CSS or JS

# tell the installer it has nothing left to do
echo OK > storage/app/installed

migrate --seed runs the setup seeders: the default location, departments and designations, leave types, pipeline stages, ticket categories, task statuses, and the admin@nexus.test account with the password password. Those seeders are idempotent — running them twice does not duplicate anything.

Demo mode

Setting APP_DEMO=true in .env turns an install into a public demo. Two things change: the sign-in page opens prefilled and offers the seeded accounts as one-click tiles, and Settings → Backup & Update grows a Reset demo data button. Leave it false on a real install and neither exists.

The reset drops every table, migrates, seeds the foundation and rebuilds the twelve-person demo company, then deletes any uploaded file the rebuilt database no longer points at. It takes about a minute and signs everybody out, including whoever pressed the button. The same thing runs from the command line:

php artisan demo:reset

To have the demo put itself back on its own — so whatever one visitor did to it is gone before the next one arrives — add one crontab line on the demo server:

0 * * * * cd /path/to/nexus && php artisan demo:reset >> /dev/null 2>&1

That is the only cron entry Nexus ever wants, and only a demo wants it: nothing else in the product is scheduled, so a real install still needs no cron at all.

Around the screen

Four things sit outside the modules and are worth knowing before you start.

The language switcher is in the user menu, alongside your profile and sign out. It offers whichever languages are switched on in Settings → Languages.

General settings

Settings → General Settings. Three tabs. Each saves only its own fields, so correcting the currency cannot blank the company address.

The legal name, address and tax number are what appear on printed quotes, invoices and contracts — not the application name, which is the label in the sidebar.

Module settings live on their own screens, because each is a set of records rather than a set of switches: HR Settings, CRM Settings and Project Settings.

Locations

Settings → Locations. An office, a site, a country. Every person belongs to one, and one location is the default that new people get.

Locations matter in three places: holidays are declared per location, so a Turkish office and a German one keep their own calendars; leave day counting skips the holidays of the requester's location; and attendance and headcount reports can be filtered by location.

A location cannot be deleted while people are attached to it — move them first.

Users & roles

Settings → Users & Roles. The same list as Employees, seen from the access side: who can sign in, as what, and with which sections open to them.

Seven roles ship. A role is a starting point, not a cage — it sets a sensible set of permissions when you create somebody, and you tick or untick from there.

Deactivating somebody (the toggle on the row) stops them signing in immediately and kills their API tokens with them, without deleting anything they did. That is the right move when a person leaves: their name stays on the deals they won and the tasks they finished.

Permissions

Access is by section, not by screen. Twelve sections exist, and each one is a tick box on a person's record:

What everybody gets

Self-service needs no section. Every signed-in person can see their own attendance, book their own leave, read their own payslips, claim their own expenses, fill in their own timesheet, track their own goals and see the tasks assigned to them — scoped to themselves, always. See My workspace.

Approvals are the other unpermissioned door: anybody who has people reporting to them gets an Approvals screen for their own reports, without being handed the whole HR module.

Hiding a menu item is presentation; the middleware on the route is the actual guard. A person who types a URL they may not have gets a 403, not the page.

Departments & designations

People → Departments and People → Designations.

A department has a name, an optional head and an optional parent — the parent is what lets the org chart draw a tree rather than a row. A designation is a job title, and it is what shows under a person's name across the whole product.

Neither can be deleted while somebody is in it. Both are used as filters on almost every HR list and report, which is the real reason to keep them tidy.

Employees

People → Employees. The directory, and the record every other HR screen hangs off.

Adding somebody

Name, email and role are required; everything else can follow. The fields that matter later:

The employee code is generated: a prefix from settings plus the next free number, zero-padded. Codes already handed out are never reused, so a code always points at one person for the life of the system.

The employee record

Tabs across the top: profile, attendance, leave, documents, assets, salary, goals and reviews. Everything on those tabs is the same data the module screens show, filtered to this person — there is no second copy.

Salary is its own screen, and needs the payroll section: the basic amount, the pay frequency and the components attached to this person. See Salary structures.

Org chart

People → Org Chart. The reporting tree, drawn from the manager on each person's record. Click a node to open the person.

Anybody with no manager is a root. If the chart looks like a lawn rather than a tree, somebody's manager field is empty.

Onboarding

People → Onboarding. Checklists for a new starter — the laptop, the accounts, the contract, the first-week introductions.

Build a template once as a list of tasks, then assign it to a person. That copies the tasks onto them with due dates counted from their start date. The screen shows every open checklist and what is outstanding on each; tick items off as they happen. A candidate hired through recruitment can have a checklist attached at the moment they are converted into an employee.

Documents

People → Documents. Every file attached to a person, in one list — contracts, certificates, ID copies, right-to-work papers — each with a category and an optional expiry date.

Expiry is the point of the screen. Filter to expiring within 30 days or already expired, and the counts at the top say how many of each there are, so a visa or a certification does not lapse quietly.

Documents are uploaded on the person's own record, not here — this screen is the overview across everybody. Files are stored under public/uploads/ and are reachable only through the app.

Announcements

People → Announcements. Company notices, optionally scoped to a department or a location and optionally pinned. Published announcements appear on the dashboard for the people they are aimed at; drafts appear to nobody.

Company assets

People → Company Assets. Laptops, phones, keys, cars — anything issued to a person and expected back.

An asset has a name, an asset tag, a category, a serial number, a purchase date and a cost. Two buttons drive it: Assign hands it to somebody from a date, and Return takes it back. Each assignment is kept, so the asset shows every person who has held it and the person shows what they currently hold — which is the list you want on a leaver's last day.

Working time rules

Settings → HR Settings. Five tabs of policy that the rest of the HR module reads. Set these before you start recording anything, because they change what recorded data means.

Attendance

Time & attendance → Attendance. A month at a time, everybody down the side, days across the top, one coloured cell each.

How a day gets recorded

Four actions make a day: in, break start, break end, out. People clock themselves from My Attendance or through the API; HR can also type a day in directly if allow manual attendance is on. Every row records where it came from, so a hand-entered day is distinguishable from a clocked one.

When the day is closed, the worked minutes are computed as the span between in and out minus any breaks, and the day is marked against the schedule: present, late (past the start time plus the grace minutes), half day, absent, on leave or a holiday. That status is what the grid colours and what payroll later reads.

The grid

Click any cell to open that person's day and correct it. The screen also does the two bulk jobs: Export writes the month out as CSV, and Import takes a CSV from a biometric device or a spreadsheet.

The import wants a header row. Identify the person with either employee_code or email, and give at least a date:

employee_code,date,clock_in,clock_out,break_minutes,status,note
EMP-0004,2026-08-24,09:02,17:35,45,,
EMP-0007,2026-08-24,,,,absent,Called in sick

Rows naming nobody, or with no date, are skipped rather than guessed at, and the message afterwards says how many landed and how many did not. Imported rows are marked as such, so they stay distinguishable from clocked ones.

Approved leave and holidays are drawn into the grid automatically. Nobody has to mark a public holiday as an absence.

Timesheets

Time & attendance → Timesheets. One row per person per week: the minutes worked each day, the week's total, and the overtime in it.

Press Build to generate the week's sheets from the attendance already recorded — for everybody, or for one person. Building again refreshes any sheet still in draft or rejected, and leaves submitted and approved ones alone, so it is safe to press twice.

A sheet moves draft → submitted → approved or rejected. People submit their own from My Timesheet, where they can also correct the daily figures before sending them; managers decide from here or from Approvals.

Shifts & rosters

Time & attendance → Shifts & Schedules. A shift is a named pattern — a start, an end, a break allowance and which days it covers. Everybody who has no shift assigned follows the company default from HR settings.

The roster view assigns people to shifts across a week. Assigning changes what "late" means for that person and what a full day of theirs is worth, which is how a part-time or night-shift employee stops looking permanently absent.

Holidays

Time & attendance → Holidays. Public holidays, per year, per location. A holiday can apply to every location or just one.

Holidays are subtracted everywhere it matters: they are not working days for leave counting, they are not absences on the attendance grid, they do not cost pay, and the workload chart does not expect anybody to be at their desk. Load next year's before December — leave requests that straddle the new year need them.

Leave

Time & attendance → Leave Requests and Leave Types.

Leave types

A type is the policy. Each carries:

Either accrual prorates a hire year: somebody who joins in September does not get twelve months of holiday.

Balances

A balance row exists per person, per type, per leave year, and is created the first time it is needed. It holds what was allocated, what was carried in, what has been taken and what is pending. Two buttons on the Leave Types screen manage them: Allocate recalculates entitlements for a year, and Adjust writes a manual correction against one person with a reason — which is how you handle a one-off grant without lying about the policy.

Requesting and deciding

People file from My Leave: a type, a date range, an optional half day, and a reason. Nexus counts the working days in the range, skipping weekends and the holidays at that person's location — a half day on a single date counts as 0.5 — and refuses the request if the balance will not cover it or the notice is too short.

The request goes to the person's manager, who approves or declines it here, from Approvals, or from the email. On approval the days move from pending to taken, the attendance grid fills in, and the leave lands on the shared calendar so nobody schedules a workshop into it. The requester is notified either way, and may cancel a pending request themselves.

The Leave calendar tab shows the whole team's booked leave in a month view — the screen to check before approving anything.

Salary structures

Payroll → Salary Structures defines the components; each person's own structure is on their record, under Salary.

A component is an earning or a deduction, calculated either as a fixed amount or a percent of basic. Housing allowance, transport, a pension contribution, a union fee — you define the vocabulary your country uses.

A person's structure is their basic amount, a pay frequency (monthly, weekly or hourly) and the components attached to them with a value each. That is everything payroll needs about them; the rest it reads from the clock.

Pay runs & payslips

Payroll → Pay Runs. A run covers a period and a set of people, and moves draft → approved → paid.

1. Create the run

   Pick the period start and end. Nexus takes the next reference number and generates a draft payslip for every employed person with a salary structure.

2. Read the payslips

   Each is built from the structure, the attendance and leave in the period, the timesheets approved in it, the expense claims approved and not yet reimbursed, and the loans being repaid. Every line shows where it came from.

3. Fix and regenerate

   Corrected an absence or approved a late timesheet? Press Regenerate and the draft is rebuilt from current data. Only a draft can be regenerated.

4. Approve

   Freezes the figures. Nothing recalculates after this point.

5. Pay

   Marks the run paid, stamps the payslips, reduces the loan balances by the instalments taken, and marks the reimbursed expense claims as paid. The payslip_ready notification goes out if it is switched on.

What a payslip is made of

The day rate is the basic divided by the working days in the period — weekends and that person's location holidays excluded — and the hourly rate is the day rate over their scheduled hours. Nothing is rounded until the payslip is written, so the lines add up to the total exactly.

Gross is the sum of the earnings, deductions the sum of the deductions, and net the difference. Print gives a payslip laid out for A4 or PDF; Email payslips sends each person theirs; and everybody can read their own from My Payslips whether or not you email them.

Loans & advances

Payroll → Loans & Advances. A loan has a title, an amount, a number of instalments and a start date. From that start date, each pay run deducts one instalment and reduces the remaining balance when the run is paid.

A salary advance is the same record with one instalment. The person's payslip always shows what was taken and what is left, so nobody has to keep a side spreadsheet.

Expense claims

Payroll → Expense Claims. Staff file claims from My Expenses: a category, an amount, the date it was spent, a note and a receipt.

A claim runs pending → approved or declined → paid. The manager or payroll decides; the claimant is notified. A claim can be marked paid by hand here, or left to the next pay run, which reimburses every approved unpaid claim on the payslip and marks them paid when the run is paid. Either way a claim is only ever paid once.

The categories come from HR Settings → Payroll & expenses.

Jobs & candidates

Talent → Job Openings and Candidates.

An opening has a title, a department, a location, an employment type, a description, a number of seats and a status. Published openings appear on the careers page; drafts and closed ones do not.

Candidates sit on a kanban by stage — new, screening, interview, offer, hired, rejected — and move by dragging. Each records a source (careers page, referral, LinkedIn, job board, agency, other), so you can see which channel actually produces hires. A CV and any other files attach to the record, and a rating out of five can be set from the card.

Interviews & hiring

Talent → Interviews. Book an interview against a candidate: a date and time, a length, a place — a room or a meeting link — and a panel of interviewers. Everybody involved is notified and the interview appears on the shared calendar. The interview itself runs scheduled → completed or cancelled.

Afterwards each member of the panel leaves their own feedback: a rating, written comments and a recommendation of hire, hold or reject. One entry per interviewer, so the decision is made against something written down rather than the loudest memory in the room.

Hiring

Press Hire on a candidate and Nexus creates the user account, allocates the employee code, attaches an onboarding checklist if you choose one, moves the candidate to hired, and counts a seat filled on the opening. The candidate record stays, linked to the person, so you keep the whole history of how they arrived.

Careers page

A public page at /careers, outside the login, listing every published opening. Each has its own page with the description and an application form: name, email, phone, a message and a CV upload. A submission creates a candidate at the new stage with the source set to the careers page.

Switch the page on or off, and write the introduction that sits above the list, in HR Settings → Careers page. The page follows the site theme and the visitor's language.

Goals & OKRs

Talent → Goals & OKRs. A goal belongs to a person, has a title, a description, a due date and a progress percentage, and runs active → completed or cancelled.

Under a goal sit its key results — the measurable parts. Each has a title, a target, a current value and a unit, so "grow trial sign-ups" becomes "trial sign-ups: 340 of 500". Moving a key result's current value is what moves the goal's progress; nobody types the percentage.

Goals can also nest: give one a parent and a company objective carries the team goals underneath it, each with its own owner. The goal page shows the children and where each has got to.

People update their own from My Goals. Goals appear on the employee record and feed the review conversation rather than being scored automatically — the number is a prompt, not a verdict.

Performance reviews

Talent → Reviews. Reviews happen in cycles: a name, a period, a due date and a question set (the default comes from HR settings, and each cycle can differ).

Opening a cycle hands every employee two forms — a self review for them and a manager review for their manager. Each question is rated one to five with room for comment. A submitted form is scored as the mean of its ratings, so a person's cycle shows their own score beside their manager's, and the gap between the two is usually the conversation worth having.

The cycle screen tracks who has submitted and who has not.

Training

Talent → Training. A course or session: a title, a trainer, a date, a location, a cost and a description.

Add attendees from the training record; mark who actually attended afterwards. Each person's completed training shows on their employee record, which is what a certification audit asks for.

Warnings

Talent → Warnings. Disciplinary records: the person, a severity — verbal, written or final — the date it was issued, who issued it, and the reason.

A warning can be acknowledged by the employee, which timestamps that they saw it. Warnings need the performance section — they are not on the employee record for a colleague with only the employees permission to read.

My workspace

Every signed-in person has this group, whatever their role. Everything in it is scoped to them; there is no way to reach somebody else's row through these screens.

Approvals

My workspace → Approvals. One queue with three tabs: leave requests, timesheets and expense claims filed by the people who report to this person.

This is the screen a line manager lives in, and it needs no HR permission at all — managing people is not the same as running HR. Decisions taken here are identical to those taken from the module screens: the same rules, the same notifications, the same entries in the activity log.

Leads

CRM → Leads. A lead is somebody who is not yet a contact: a name, a company name as they said it, an email, a phone, a source, a status and an owner.

Statuses (new, contacted, qualified, unqualified by default) and sources are yours to define in CRM Settings. Email sends one of your templates to the lead and files the send as an activity.

Importing

Import takes a CSV with a header row, and lets you set an owner and a source for the whole file. These columns are recognised; anything else is ignored:

name,email,phone,company,job_title,status,source,value,notes

Export writes the filtered list back out in the same shape.

Converting

Convert turns a lead into a contact, optionally a company, and a deal at the top of a pipeline, in one step. The lead is kept and points at all three, so the source and the campaign it came from survive into the reports — which is the only way to answer "which channel produces revenue" rather than "which channel produces leads".

Deals & pipelines

CRM → Deals. A deal is an opportunity: a title, a value, a company, a contact, an owner, an expected close date and a stage.

Pipelines

Settings → CRM Settings → Pipelines & stages. A pipeline is an ordered set of stages, each with a colour and a probability. New pipelines start with the standard six — New 10%, Qualified 25%, Proposal 50%, Negotiation 75%, Won 100%, Lost 0% — and you rename, reorder, add and delete from there. One pipeline is the default; a company with a direct and a channel motion runs two.

The probability is what makes the forecast mean something: weighted pipeline is the sum of each open deal's value times its stage probability. Move the stages, and the forecast moves with them.

Working the board

The board view is the pipeline as kanban — drag a deal to move it, column totals at the top. Won and Lost close a deal; losing asks for a reason from the list in CRM settings, which is what turns "we lose a lot" into "we lose on price". Reopen puts a closed deal back. Every move is logged and the owner is notified when a deal is handed to them.

A deal's page carries its activities, quotes, comments and files, so the whole story of an opportunity is on one screen.

Contacts & companies

CRM → Contacts and Companies.

A company is the organisation: name, industry, website, phone, address, owner. A contact is a person, optionally at a company, with a job title, email and phone. Deals, quotes, invoices, contracts and tickets all point at one or both, which is what makes a company page a full account view — everything sold, billed and asked, in one place.

Two buttons matter on a contact. Email sends a template and files the activity. Portal access gives that contact a password for the client portal; revoking it shuts the door without touching anything else.

Activities

CRM → Activities. Calls, meetings, emails and to-dos, each against a lead, contact, company or deal, with a due date and an owner.

Open activities with a due date appear on the shared calendar and on the dashboard of whoever owns them. Marking one complete stamps it and drops it out of the queue. The timeline on a deal or contact is these records in date order — the answer to "when did we last talk to them".

Campaigns

CRM → Campaigns. A named marketing effort: a type, a period, a budget, the actual cost so far, an owner and a status. Leads carry the campaign they came from, so a campaign's page shows what it produced — leads, deals created, deals won and the revenue against the spend.

Nexus does not send bulk mail — see Deliberately not here. A campaign here is the record you attribute against, not a mail blaster.

Email templates

CRM → Email Templates. Reusable subjects and bodies for the Email button on a lead or a contact, and for canned replies on tickets.

Merge fields are written in double braces:

{{contact.first_name}}   {{contact.last_name}}   {{contact.email}}
{{company.name}}
{{deal.title}}           {{deal.value}}
{{user.name}}            {{user.email}}
{{app.name}}

Unknown fields render as nothing rather than leaking the placeholder into a customer's inbox. Preview shows the template filled with real data before you send it to anybody.

Web forms

CRM → Web Forms. A hosted form that creates a lead. Choose the fields, the source to stamp on submissions, and who owns what comes in.

Each form gets a public URL with an unguessable key — share the link, or drop it in an iframe on your marketing site. Regenerate issues a new key and kills the old link, which is what you press when a form starts collecting rubbish.

Products & services

Sales → Products & Services. A catalogue of what you sell: a name, an SKU, whether it is a product or a service, the unit it is sold in, the price, your cost and a tax percentage. Quote and invoice lines are picked from here — choosing one fills the description, price and tax so nobody retypes them, and the cost is what a margin is measured against.

Lines can also be typed freehand, so a one-off does not need a catalogue entry.

Quotes

Sales → Quotes. A quote is a numbered document for a company or contact, optionally against a deal, with lines, a discount, tax and a validity date.

The line editor

Add lines, pick a product or type your own, set quantity, price, discount and tax. The running total updates as you type, and it is computed exactly as the server will compute it: a document-level discount is spread across the lines pro rata, and tax is charged on what remains after it. The number you watch is the number that gets stored.

The life of a quote

Draft → sent → accepted, declined or expired. Send emails it to the client contact and marks it sent. Print gives the A4 document with your logo, legal name, terms and footer. Duplicate copies it for the next near-identical job.

Clients respond in one of two ways: the public link on the emailed document, or the client portal. Either way accepting or declining stamps the quote and tells the owner.

Convert to invoice copies the accepted quote — lines, discount, tax and all — into a draft invoice, and links the two.

Invoices

Sales → Invoices. Same document, same line editor, plus money coming in.

An invoice is draft, sent, partial, paid, overdue or cancelled. Sent is what starts the clock: the due date comes from the payment terms in Settings → Money & invoicing, and an unpaid invoice past it shows as overdue without anybody marking it. Partial appears as soon as a payment arrives that does not cover the balance; paid when it does.

Print gives the A4 document, Send emails it with a public link the client can open without a login, and the portal lists it for contacts who have access.

Recurring invoices

An invoice can be marked recurring with a period. Press Issue due invoices on the invoice list and every recurring parent that has come due produces its next copy as a draft.

Payments

Sales → Payments. A payment records money received against an invoice: the amount, the date, a method and a reference.

Part payments are ordinary — record each as it arrives, and the invoice moves to partial and then paid on its own. The payments list is the answer to "what came in this month", filterable by method and date, and the aged debt table in the sales report is built from what is still outstanding.

Contracts

Sales → Contracts. A service agreement, maintenance, subscription, NDA or anything else: a client, a type, a value, a start and end date, and the body of the agreement.

Draft → sent → signed, and expired or terminated at the end. Send emails the client a link to the contract as a web page they can read and sign — a typed name and a timestamp, recorded with their IP address. Print gives the paper version with your letterhead.

Tickets & SLA

Sales → Support Tickets. A numbered ticket per issue: a subject, a category, a priority, a contact, an assignee and a status.

Tickets run open → pending → resolved → closed. Pending means waiting on the client — and a client reply on a pending ticket reopens it automatically, which is exactly the behaviour that stops things going quiet and getting forgotten.

The SLA clock

Every ticket gets a first-response target from its priority. The defaults are set in CRM Settings → Tickets & SLA:

The first staff reply stamps the response time. A ticket past its due time with no reply carries a breached badge, and the breach rate is on the dashboard and in the reports.

Replying

A reply is either public — emailed to the client, visible in their portal — or an internal note, which stays inside the team. Canned replies are your email templates, offered on the reply box already merged for this ticket's contact, so picking one drops finished text in rather than something you still have to edit.

Either side replying raises the bell for the other. A client reply on a pending ticket reopens it and notifies the assignee; the first staff reply stamps the response time against the SLA.

Tickets can be created here, by a client in the portal, or over the API — which is how you point a support mailbox or a contact form at it.

Knowledge base

Sales → Knowledge Base. Articles with a category, a title, a slug and a body. An article marked public is readable at /kb/{slug} without a login, so you can link one from an email or a ticket reply; the rest stay internal. Each article counts its views, which over a few months tells you what your customers actually keep asking.

Clients reach the knowledge base from the portal, and agents from the ticket screen — which is where an article most often saves a reply.

Client portal

A separate front door at /portal for your clients. It is not the back office with things hidden: it is a different set of screens on a different login, and staff never use it.

Give a contact access from their record in CRM → Contacts — set a password and they can sign in. Turn the whole portal off in CRM Settings → Client portal; every portal address then returns a 404 rather than a login form.

Sign-in is rate limited to five attempts a minute per email and address, and a client only ever sees documents belonging to their own company.

Projects

Projects → Projects. A project has a name, a code, a client company and contact, a category, an owner, a period, a status, a priority, a budget and a colour.

Two fields decide how it bills: billable, and the hourly rate that logged time is charged at. A member can carry their own rate, which overrides the project's — see Billing a project.

Statuses are planning, active, on hold, completed and archived. Progress is a percentage Nexus keeps up to date: the share of the project's tasks that are done. Nobody types it.

Members and access

The Members tab is who works on it, each as a viewer, a member or a manager. This is the one place in Nexus where access is per-record rather than per-section:

So a developer with no HR or CRM access and no projects permission still opens the two projects they were added to, and nothing else.

Tasks

Projects → All Tasks for everything, or the Tasks tab inside a project.

A task carries a title, a description, a status, a priority, assignees, a start and due date, an estimate in hours, labels and a milestone. Priorities are fixed — low, medium, high, urgent — because every screen colours them. Everything else you define in Settings → Project Settings: the statuses that become board columns, the labels, and the project categories.

Structure

Assigning a task notifies the assignee. Every status change is logged, and finishing a task refreshes the project's progress figure.

Board, gantt & calendar

The same tasks, four ways. Each is a tab on the project.

A task with no dates does not appear on the gantt or the calendar; that is usually the explanation when something seems missing from them.

Milestones & sprints

Milestones are dated markers within a project — a delivery, a sign-off, a release. Tasks point at one, so a milestone shows how much of what it depends on is done, and it appears on the gantt and the shared calendar.

Sprints are a period with a set of tasks and a goal. The sprint page draws a burndown: the estimated hours still open at the end of each day, against the straight line the team would follow finishing at an even pace. Days that have not happened yet are left blank rather than drawn flat, so the chart stops at today and does not imply a plateau that has not occurred.

Issues, notes & files

Three more tabs on a project, for the things that are not tasks:

Time tracking

Projects → Time Tracking, or the timer on any task.

Two ways to log time: press Start on a task and stop it when you are done, or type an entry with a date, a duration and a note. One timer runs per person, so starting a second stops the first.

Stopping a timer rounds the duration up to the block set in Settings → Project Settings — with the default fifteen minutes, seven minutes becomes fifteen and sixteen becomes thirty. The rounded figure is what gets stored, so the entry matches what gets invoiced.

Billable and approved

Entries are billable or not; the default for new entries is a setting. If time approval required is on, entries must be approved before they can be invoiced — the list has per-row approve and reject, and an Approve all for a filtered selection.

Export writes the filtered list as CSV, which is what most people actually want when a client asks for a breakdown.

Workload

Projects → Workload. Estimated hours of open work due per person per week, against what their week can actually hold — hours per day times the working days, holidays excluded.

An estimate on a task shared by several assignees is split between them rather than counted twice. Over-capacity weeks are coloured, which makes this the screen to open before promising a date.

Only tasks with an estimate and a due date can be planned, so a blank-looking workload usually means the estimates are missing, not that the team is free.

Project templates

Projects → Templates. A reusable project shape: milestones and tasks with their dates expressed as offsets — day 0, day 5, day 30 — rather than as fixed dates.

Creating a project from a template asks for a start date and applies the offsets from it. Whoever creates it becomes the owner. For an agency that runs the same onboarding on every client, this is the difference between a day of setup and a minute.

Billing a project

The one place the Projects module touches Sales. On a project, Invoice time collects every billable, approved, not-yet-billed time entry and every unbilled billable expense, and creates a draft invoice for the project's client.

Before you commit to it, the screen previews what would be billed: the hours, what they come to, the expenses, and the total.

The entries and expenses are stamped as billed against that invoice, so the same hour is never invoiced twice. The invoice is a draft: check it, edit the lines, then send it like any other.

If time approval required is off, entries are approved as they are logged and are billable straight away. If it is on, nothing reaches an invoice until somebody approves it — which is the point of turning it on.

Dashboard

The dashboard is assembled from what you are allowed to see. A sales user gets pipeline and revenue; an HR user gets headcount, attendance and who is off today; a project manager gets delivery. Somebody with all three gets all three, in that order. Nothing is computed for a section you cannot open, so a narrow account is a fast page.

Headline figures show their change against the previous period, because a number without a direction is decoration.

Reports

Three report screens, each a set of tables with charts over them, and each table downloadable as CSV from the button beside it. Same numbers on screen, in the chart and in the file.

Every report takes a period — a preset or your own date range — and the filters you would expect. All three need the reports section.

Activity log

Reports → Activity Log. Every state change in the system: who, what, when, from which address, and against which record.

Leave decided, a deal won, an invoice sent, a payslip paid, a setting changed, a backup taken, a failed email — all of it. Filter by person, by action or by date, and open the record from the row.

This is where to look when somebody asks who changed something, and where a failed notification email is recorded — the mail is wrapped so that a mail server being down can never stop a leave request being filed, and the failure lands here instead of on the screen.

Notifications & email

Settings → Notifications. Two things on one screen: how mail leaves the building, and which events raise one.

Mail

Choose SMTP, sendmail or log, set the host, port, username, password and encryption, and the from address and name. Send test email proves it before you trust it. Saving writes the values to .env and re-binds mail immediately — no restart, no cache clear. Leaving the password blank means "leave it alone", not "clear it".

The log mailer writes messages to storage/logs instead of sending them, which is the right setting on a staging copy that must not email real clients.

Events

Ten events exist. Each raises the bell always, and sends an email only if its switch is on:

An optional admin copy address receives a copy of everything, which is useful while you are setting the system up and noise afterwards.

REST API

For a mobile clock-in app, a website that files leads, a status board of your own, or a support mailbox that raises tickets.

Tokens

Settings → API Tokens. Create a token, choose which member of staff it acts as, and optionally limit it to particular sections. The token is shown once — only a hash is stored, and a token list that can show you the secret is a token list that leaks every secret.

A token can never do more than its owner. Take a permission away from somebody, or deactivate them, and their integrations lose it at the same moment.

Calling it

curl https://yourdomain.com/api/v1/ping \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Accept: application/json"

Every response has the same shape — the payload under data, paging under meta — so a client never has to guess where to look. List endpoints take ?per_page= (clamped to 200) and ?page=.

{
  "data": [ { "id": 4, "name": "Amira Haddad", "employee_code": "EMP-0004" } ],
  "meta": { "page": 1, "per_page": 50, "total": 12, "last_page": 1 }
}

Endpoints

Rate limits and errors

120 requests a minute per token by default (Settings → General Settings → API), counted per token rather than per address, so several integrations behind one office connection do not throttle each other.

Every API call runs as a real member of staff, so it appears in the activity log under their name with the token noted.

Languages

Settings → Languages. Eight languages ship complete: English, French, Spanish, German, Portuguese, Turkish, Hindi and Arabic. Arabic switches the whole interface to right-to-left — layout, icons, tables and charts.

Tick which languages appear in the switcher, and pick the default for people who have not chosen. The default is always kept in the active list, so the switcher can never offer a language the site will not serve.

Translating

Nexus ships no English language file: every string in the source is its own key, so the untranslated product is English by construction and a missing translation degrades to readable English rather than to messages.save.

That means you never need a template. Open a language and the screen lists every string in the product with its translation beside it — filter to the untranslated ones and type. Four buttons help:

Files live in lang/, one JSON per locale. To add a language beyond the eight, add it to config/languages.php with its native name and direction; it then appears here to be translated.

Backups

Settings → Backup & Update. Take a backup writes every table to a timestamped .sql file in storage/app/backups, and the list below lets you download or delete them.

The dump is written in PHP rather than shelled out to mysqldump, because plenty of shared hosts disable exec() — and a backup feature that works on the developer's laptop and nowhere else is worse than none, since the buyer only finds out on the day they need it. The output is plain SQL any MySQL client will restore, so a backup taken here is not hostage to this product.

Restoring

There is no restore button, deliberately — see Deliberately not here. Restore the file the ordinary way:

mysql -u USER -p DATABASE < nexus-2026-08-26-031500.sql

Or import it through phpMyAdmin, which is what most shared hosting offers. Take a fresh backup before you restore an old one.

Updating

An update is a file copy and a migration. There is no auto-updater: one that half-finishes over a live company is worse than four steps you can see.

1. Back up

   Take a database backup from Settings → Backup & Update and download it, and copy public/uploads/ and your .env somewhere safe.

2. Copy the new files over

   Overwrite everything except .env, public/uploads/ and storage/. Those three are your data.

3. Migrate

   Run php artisan migrate --force if you have shell access. If you do not, delete storage/app/installed and open /setup — the wizard runs the outstanding migrations and re-seals itself without touching your data, as long as you leave Drop existing tables off.

4. Clear the caches

   php artisan optimize:clear, or delete the files in bootstrap/cache/. Then hard-refresh the browser once.

The version you are running is on the same screen, beside the PHP and Laravel versions and the database name — which is the first thing to quote when you ask for support.

Troubleshooting

When something goes wrong on the server, storage/logs/laravel.log has the detail. Turn APP_DEBUG on in .env only long enough to read the error, and turn it off again — it shows stack traces to everybody, including visitors.

Deliberately not here

Every link in the sidebar opens a real screen. A few things a system like this could plausibly do are absent on purpose, and this guide would rather name them than let you find out:

• No cron and no queue worker. Nothing is scheduled and nothing is queued. Emails go out inline, and recurring invoices wait for a button. That is what lets Nexus run on hosting that forbids long-running processes.
• No payroll tax engine. Rates and bands change by country and by year, and one that is subtly out of date is worse than none. Model them as deduction components.
• No payment gateway. A payment records money that arrived in your bank. Taking cards would tie the product to particular acquirers, and the ones worth integrating with differ in every country.
• No bulk email sender. Campaigns are the record you attribute revenue against. Sending thousands of messages from a shared host is how a domain gets blacklisted; use a mail platform and attribute the results here.
• No qualified e-signature. Contract signing records that a named person agreed, with a timestamp and an address. Where the law demands more, sign elsewhere and attach the PDF.
• No restore button. Restoring overwrites everything, and a mis-click there costs a company its history. The command is on the screen instead.
• No automatic updater. One that half-finishes over a live company is worse than four steps you can see.
• No accounting ledger. Nexus invoices and records receipts; it is not double-entry books. Export the sales reports into whatever your accountant uses.

Changelog

1.0.0

First release.

• People & HR — employees, org chart, departments, designations, onboarding checklists, documents with expiry, announcements, company assets; attendance with clock-in, import and export; weekly timesheets; shifts and rosters; holidays per location; leave with accrual, carry-over and balances; payroll with salary structures, pay runs, payslips, loans and expense claims; recruitment with a public careers page; goals, review cycles, training and warnings; employee self-service.
• CRM & Sales — leads with import and conversion; deals on a kanban with weighted pipelines; contacts and companies; activities; campaigns; email templates with merge fields; web-to-lead forms; products; quotes; invoices with part payments and recurring issue; contracts with online signing; support tickets with SLA; knowledge base; client portal.
• Projects — projects with per-project membership; tasks in list, board, gantt and calendar; subtasks, dependencies and recurring tasks; milestones; sprints with burndown; issues, discussions, notes, files and expenses; time tracking with timers, rounding and approval; workload; templates; invoicing from tracked time.
• Platform — role-aware dashboard with trends, global search, shared calendar, notifications by bell and email, activity log, roles and permissions, locations, settings, database backups, REST API with scoped tokens, eight languages with RTL, theme customizer, and a web installer.

Credits & support

Nexus is built on Laravel with the Tabler interface, Alpine.js for the interactive pieces, Chart.js for the charts, Tabler Icons and Vite for the build. Thanks to everyone who maintains them.

Getting help

When you write in, three things turn a slow answer into a fast one: the version from Settings → Backup & Update, the exact steps that produced the problem, and the last few lines of storage/logs/laravel.log. A screenshot of the screen you were on helps more than a description of it.

Nexus documentation · version 1.0
Thank you for buying it.