Suntel360 · Platform
Four products, one engineering standard
ERP, HRMS, ATS and CRM each run as their own multi-tenant cloud service. They are not one system pretending to be four — they are four, built the same way, and this page draws the boundaries as they actually are.
- Independent services, independent tables, independent access control
- One production integration today, documented rather than implied
- Defined in version-controlled templates
4
Independent products
41
Shipped modules
150
Record types
1
Cross-product integration
Topology
What the architecture really looks like
The usual suite diagram shows a shared core with four modules plugged in. Ours would be a lie. Here is the honest version.
ERP
Inventory, accounting, and operations on one general ledger
- Its own data store
- Its own compute
- Its own access control
HRMS
The employee lifecycle from onboarding through payroll
- Its own data store
- Its own compute
- Its own access control
ATS
A hiring pipeline from requisition to offer, synced with HRMS
- Its own data store
- Its own compute
- Signs in against HRMS records
CRM
Contacts, deals, and pipeline forecasting in one workspace
- Its own data store
- Its own compute
- Its own access control
The one edge that exists
ATS → HRMS. ATS authenticates every request against the requester’s HRMS employee record, and writes hiring-team job assignments back to that record. Job identity, team, and status — nothing else. No candidate or application data crosses the boundary, and nothing flows the other way.
Managed cloud, defined in version control
Every product runs as a managed cloud service, defined in version-controlled templates. There is no server for your team to patch.
Multi-tenant isolation in every product
Every request is scoped to your organisation. In ERP the tenant is part of every storage key; in HRMS, ATS and CRM the organisation is checked on the records each request returns. Every record belongs to exactly one tenant.
Access checked on every request
In ERP, HRMS and CRM, permissions resolve fresh against a live lookup on each request rather than being baked into a long-lived token — so revoking access takes effect on the next call, not the next login. ATS has no login of its own and authenticates against the same HRMS employee record.
State machines, not status fields
Documents move through defined states with defined transitions. A submitted record is not edited in place; it is cancelled and superseded. That is what makes an audit trail worth reading a year later.
Audit logs kept separately from the record
In HRMS, ATS and CRM, history is written to its own log rather than inferred from the current state of a row, so who changed what survives every later edit.
One vendor accountable for all four
The same team builds, deploys and supports every product to the same operational standard. There is no integration partner to escalate through when two products disagree.
Live integration
What connects today
One integration runs in production. When a hiring team is assigned to a job in ATS, each team member's HRMS employee record is updated with that assignment — and ATS authenticates every request against that same record.
- Step 1 · ATSA job's hiring team is set or changed in ATS
- Step 2 · HRMSEach hiring-team member's employee record is updated with that job assignment
Step 1, ATS: A job's hiring team is set or changed in ATS. Step 2, HRMS: Each hiring-team member's employee record is updated with that job assignment.
Order to Ledger
Inside ERP: a quotation becomes a sales order, then a delivery and an invoice that each post to the general ledger.
- 01ERP·Quotation submitted
The quotation is submitted and locked. A change after submission means cancelling it and amending a new version, so the history stays intact.
Customer: Sample Customer LtdItems: 450 × bearingTotal: $120,000 - 02ERP·Sales order from the quotation
The sales order is created from the submitted quotation, carrying the customer, items and prices across.
From: QTN-0142Payment terms: Net 30Lines: Copied from quotation - 03ERP·Delivery note issues stock
A delivery note is created from the sales order. Submitting it issues the stock and, where perpetual inventory is enabled, posts the stock movement with its cost of goods sold.
From: SO-0412Quantity issued: 450Cost of goods sold: $81,000 - 04ERP·Sales invoice posts the receivable
The sales invoice is created from the sales order. Submitting it writes the receivable and the revenue to the general ledger in the same transaction.
From: SO-0412Receivable: $120,000Revenue: $120,000
Outcome
Stock issued, invoice raised, and every ledger line posted by the documents themselves.
Attendance to Payslip
Inside HRMS: biometric punches become daily attendance, which the payroll run reads before payslips go out.
- 01HRMS·Device punches synced
A scheduled job pulls punch records from each ESSL biometric device and files them against the matching employee record.
Device: Gate 2Employee: EMP-0217Punches: 09:02 in · 18:11 out - 02HRMS·Daily attendance resolved
Shift rules pair each day's punches, and hours worked set the daily status: present or half day, with late as a separate flag.
Shift: 09:00–18:00Holiday: NoStatus: Present - 03HRMS·Payroll run created
An authorised operator creates the payroll run, which rebuilds each employee's attendance figures first. Missing holidays block the run until someone acknowledges them.
Period: OctoberEmployees: 48Open warnings: 0 - 04HRMS·Payslips emailed
Payslips are generated as PDFs for the run and emailed to each employee.
Employee: EMP-0217Format: PDFDelivery: Email
Outcome
Payroll calculated from reconciled attendance, and each employee emailed their own payslip.
Job to Offer
Inside ATS: a job opens with its hiring team, applications are screened, interviews held and an offer made. The hiring team syncs to HRMS.
- 01ATS·Job opened with its hiring team
A recruiter opens the job and assigns the hiring team. The assignment syncs to each member's HRMS employee record, the one live link between Suntel360 products.
Role: Warehouse SupervisorHiring team: 3 membersHRMS sync: Synced - 02ATS·Application screened
A recruiter runs a resume analysis on the application. It always includes a rule-based skills match, and adds an AI match score where your organisation has switched AI screening on.
Applicant: #1288Skills matched: 7 of 9AI analysis: Completed - 03ATS·Interview scheduled
Interviews are scheduled once the application reaches the interview stage, and each interviewer records feedback against it.
Stage: InterviewPanel: 2 interviewersWhen: Tue 10:30 - 04ATS·Offer made and accepted
The offer is created in ATS and its status tracked through to acceptance, with the appointment letter sent from ATS.
Offer: AcceptedLetter: SentStart: 1 Dec
Outcome
Offer accepted. Candidate data stayed in ATS; only the hiring-team assignment reached HRMS.
Contact to Forecast
Inside CRM: a contact becomes a deal, a meeting moves it on, and the weighted forecast updates.
- 01CRM·Contact created
A contact is added by hand, by bulk import, or as a lead from the website chatbot.
Name: Sample ContactCompany: Sample Customer LtdSource: Website chatbot - 02CRM·Deal opened
A deal is opened against the contact and moves through the stages your team configured, each with its own win probability.
Value: $120,000Stage: ProposalContact: CON-0815 - 03CRM·Meeting completed
A meeting is scheduled against the deal and marked complete once it has happened.
Type: DemoWith: Sample ContactStatus: Completed - 04CRM·Weighted forecast updated
The forecast multiplies each open deal's value by its win probability (the stage's, unless the deal sets its own) and groups deals closing in the period into commit, best-case and pipeline bands.
Deal value: $120,000Weighted: $72,000Band: Best case
Outcome
While the deal is open and due to close in the period, it counts at its own win probability, or its stage's if it has none.
Design
Four products designed to one standard: tenant isolation, role-based access, and state machines, with audit logging in HRMS, ATS and CRM.
Build
Each product is an independent codebase with its own tables, its own API, and its own access control. No shared database, no suite-wide login.
Deploy
Managed cloud infrastructure defined in version-controlled templates. Region questions are answered directly on request.
Operate
One production integration today: ATS authenticates recruiters against HRMS employee records and syncs hiring-team assignments. Everything else is independent.
Review
Your reviewers get implementation detail directly: topology, tenancy model, integration roadmap, and security questionnaire under NDA.
Stack
What it runs on
The properties your infrastructure team will want before the second meeting. Specific vendors, versions and topology go to them directly rather than onto a public page.
- Hosting
- Fully managed cloud; region questions answered directly on request
- Scaling
- Capacity follows demand; no instances for you to size
- Tenancy
- Multi-tenant; every request scoped to your organisation
- Access control
- Role and permission checks resolved on every request
- Data in transit and at rest
- Encrypted throughout
- Provisioning
- Defined in version-controlled templates
- Audit
- HRMS, ATS and CRM write to a dedicated log, separate from the record
- Availability and recovery
- Reviewed with your team during procurement
Straight answers
Platform questions
How do ATS and HRMS work together?
ATS has no user store of its own. Recruiters sign in with their HRMS employee account, and ATS checks every request against that employee record. When a hiring team is assigned to a job, the assignment syncs to each member's HRMS record. Candidate and application data stays in ATS.
How is each product kept separate from the others?
Each product runs as its own multi-tenant service with its own tables and its own sign-in, and each resolves permissions on every request against its own roles. ATS is the one exception to separate sign-in: it authenticates recruiters against HRMS employee records instead of keeping logins of its own.
How is tenant data separated inside a product?
Every request is scoped to the organisation that made it. In ERP the scope is built into the storage keys themselves; HRMS, ATS and CRM check the organisation on the records each request returns. Permissions are resolved on every request, so an access change takes effect immediately rather than at next sign-in.
What do the four products have in common?
An engineering standard, a support team and a vendor, not data. All four are built and deployed the same way, run on managed cloud infrastructure, validate input on the server and hide internal error detail from users. Data and permissions stay inside each product, and apart from the ATS hiring-team sync and its sign-in through HRMS.
What does managed infrastructure mean for our team?
There is no server for your team to install, patch or harden. Each product runs on managed cloud compute and storage, stored data is encrypted at rest by default, and traffic to the products is encrypted in transit. Your people use the products in a browser; we operate everything underneath.
See the architecture in detail
We will take your team through the deployment topology, the tenancy model, and the integration roadmap.