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
- Deployed from version-controlled infrastructure, not console clicks
0
Independent products
0
Shipped modules
0
Record types
0
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, provisioned from infrastructure definitions held in version control. There is no server for your team to patch and no environment that exists only in someone's memory.
Multi-tenant isolation at the data layer
Tenant scoping is enforced where the data is read and written, not in the interface. Every record belongs to exactly one tenant, and a query that forgets to say which one does not silently return everybody's.
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
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.
Customer Order to Ledger
A sale moves from CRM quotation to ERP inventory allocation and ledger posting — end to end.
Account manager closes deal with Apex Global Logistics after final compliance sign-off.
Quotation auto-converts to a confirmed Sales Order. Customer credit terms verified instantly.
Warehouse batch SKU-8921 automatically reserved across Primary and Regional depots.
Immutable double-entry posted to Accounts Receivable and Sales Revenue.
Outcome
Order converted, 450 units reserved, ledger posted — zero manual re-entry.
Design
Four products designed to one standard: tenant isolation, role-based access, state machines, and audit logging built in from the start.
Build
Each product is an independent codebase with its own tables, its own API, and its own access control. No shared database, no shared login.
Deploy
Managed cloud infrastructure provisioned from version-controlled definitions. No console clicks, no manual configuration, no drift.
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, in the region agreed with you
- Scaling
- Capacity follows demand; no instances for you to size
- Tenancy
- Multi-tenant, isolated per product at the data layer
- Access control
- Role and permission checks resolved on every request
- Data in transit and at rest
- Encrypted throughout
- Provisioning
- From version-controlled definitions, never by hand
- Audit
- Written to a dedicated log, separate from the record
- Availability and recovery
- Reviewed with your team during procurement
Straight answers
Platform questions
Is this one product or four?
Four. Each runs as its own multi-tenant service with its own tables and its own access control. We could describe it as a single unified platform, but a technical evaluator would find out otherwise in the first architecture call, so we say it plainly instead.
Do the four products share a database or a single login?
No. There is no shared database, no common ledger across products, and no suite-wide single credential. The one live connection is ATS authenticating recruiters against HRMS employee records and syncing hiring-team job assignments back.
Then why buy them together?
Because they are built, deployed and supported to one standard by one team, and because the integrations that do exist are ones we own end to end. If you only need one, buy one — the products do not depend on each other.
Can we start with one product and add others later?
Yes. Each product stands alone, so adoption order is yours to choose. Adding a second later does not require re-implementing the first.
What is on the integration roadmap?
Deeper links across the suite — the ATS-to-HRMS hire handoff being the nearest one. We publish what runs today rather than what is planned, so this page will change when the code does.
How is it priced?
Per product, quoted against your organisation's size and the modules you actually need. There is no published price list and no self-serve trial — enterprise deployments differ too much for either to be honest.
Where does the data live?
In an encrypted, managed database scoped to your organisation, in the region agreed during deployment. We will walk your security team through the topology under NDA before you commit.
Can we see it running?
Yes. A working session against your own scenarios is how these evaluations should go — talk to sales and we will set one up.
See the architecture in detail
We will take your team through the deployment topology, the tenancy model, and the integration roadmap.