HRIS Architecture, Data and Technology Models

Introduction and Context

Human resource information systems (HRIS) are not merely electronic filing cabinets. They are integrated socio-technical systems that capture, store, transform, communicate, and govern information about people and work. Their architecture determines how reliably an organization can pay employees, administer benefits, manage talent, comply with regulation, produce workforce analytics, and support strategic decisions.

For HR professionals, understanding architecture is important for three reasons. First, data quality and system design directly affect operational outcomes: an incorrect employment status can cause an incorrect payroll result, benefits error, or access decision. Second, architecture shapes organizational flexibility. A highly configurable platform may support changing policies without expensive programming, whereas a heavily customized platform may create long-term maintenance and upgrade risks. Third, architecture embodies governance choices concerning privacy, authority, accountability, and the legitimate use of employee data.

This chapter examines the principal architectural and technological concepts that underlie contemporary HRIS: databases and data models, master data and systems of record, workflows, role-based access control, cloud and software-as-a-service (SaaS) models, mobile access, application programming interfaces (APIs), and configurable versus customized systems.

Learning Objectives

By the end of this chapter, students should be able to:

1. Explain how databases and data models organize HR information.
2. Distinguish master data, transactional data, reference data, and metadata.
3. Analyze the system-of-record concept and identify authoritative sources.
4. Explain workflows, business rules, audit trails, and role-based access.
5. Compare on-premises, hosted, cloud, and SaaS architectures.
6. Evaluate mobile platforms and APIs in an HR technology ecosystem.
7. Distinguish configuration from customization and assess their trade-offs.
8. Apply architectural reasoning to HR implementation and governance decisions.

1. HRIS as a Socio-Technical Architecture

An HRIS can be understood as a set of interacting layers rather than as a single application:

• Presentation layer: screens, portals, dashboards, and mobile interfaces through which users interact with the system.
• Application layer: business logic, validation, workflow, calculations, notifications, and reporting services.
• Data layer: databases, data warehouses, document stores, file repositories, and data-management services.
• Integration layer: APIs, event streams, middleware, file exchanges, and connectors linking the HRIS to payroll, finance, identity, learning, recruiting, and other systems.
• Governance and security layer: authentication, authorization, encryption, retention, audit, compliance, and policy controls.

These layers are conceptually distinct but operationally interdependent. A well-designed user interface cannot compensate for inaccurate data. A secure database does not by itself ensure lawful processing. An API may transfer data efficiently while still propagating an erroneous source record.

Figure: A conceptual layered architecture for an HRIS.

Architecture is also socio-technical because processes, roles, skills, incentives, and organizational culture influence how technology operates. For example, a technically valid approval workflow may fail if managers do not understand their accountability or if HR data stewards do not resolve exceptions.

2. Databases and HR Data Models

A database is an organized collection of data managed so that authorized users and applications can store, retrieve, update, and analyze information. Most core HRIS platforms use relational databases, in which data are represented in tables consisting of rows and columns. A row may represent one employee, position, or employment event; a column represents an attribute such as employee identifier, hire date, or employment status.

A relational design separates related entities and links them using keys. A primary key uniquely identifies a record within a table. A foreign key refers to a primary key in another table, creating a relationship. For example, an Employee table may contain EmployeeID, while an Assignment table contains EmployeeID and PositionID. This structure avoids repeatedly storing the same employee details in every assignment record.

A simplified conceptual model might include:

Good relational design seeks to reduce unnecessary duplication, a principle commonly associated with normalization. Normalization can improve consistency by storing a fact once and referencing it where needed. However, reporting systems sometimes deliberately use denormalized structures to improve query performance. Thus, design is not a mechanical choice: it balances integrity, performance, usability, and analytical requirements.

2.1 Data models

A conceptual data model identifies major entities and relationships without prescribing technical implementation. A logical data model specifies attributes, keys, relationships, and constraints. A physical data model describes how the design is implemented in a particular database, including indexes, partitions, storage formats, and security mechanisms.

HR data often have temporal characteristics. An employee's department, manager, job, work location, and compensation may change over time. A system must therefore distinguish current state from historical state. An effective-dated record typically includes a start date and, where applicable, an end date. If a manager change is entered without preserving the prior manager and effective date, historical reporting and accountability may be compromised.

HR data also have different structures. Structured data include dates, codes, amounts, and statuses. Semi-structured data include JSON-based API messages. Unstructured data include resumes, contracts, medical documents, and performance narratives. Treating all data as if they had identical controls is unsafe; documents may require separate access restrictions, retention rules, and classification.

2.2 Data quality

Data quality is multidimensional. Common dimensions include accuracy, completeness, consistency, timeliness, validity, uniqueness, and fitness for purpose. A record can be complete but inaccurate, or accurate but too old for a particular decision. Data quality should therefore be assessed against a defined business use rather than as an abstract technical ideal.

A useful operational measure is a completeness rate:

The measure assumes that required fields have been clearly defined and that each missing value is counted consistently. It does not establish accuracy or fairness. For example, 98% completeness in a demographic field does not prove that the populated values are correct or that employees were treated equitably.

3. Master Data, Reference Data, Metadata and Systems of Record

Master data are relatively stable, shared entities used across processes. In HR, examples include person, worker, organization, position, job, location, cost center, and employment relationship. Master data do change, but they are not primarily event records.

Transactional data record events or activities, such as a hire, absence request, salary change, time entry, training completion, or termination. Reference data are controlled lists used to classify or validate transactions, such as country codes, employment-status codes, reason codes, and currency codes. Metadata describe data, including its definition, owner, source, format, sensitivity, retention period, and update frequency.

The system of record (SoR) is the designated authoritative source for a particular data domain or business fact. A single organization may have several systems of record. The HRIS may be authoritative for employment status and organizational assignment; a payroll system may be authoritative for payroll results; a learning platform may be authoritative for course completion. “System of record” is therefore a governance designation, not necessarily a claim that one application contains every HR fact.

A related concept is the system of entry, where a user first enters or initiates information. A recruiting system may be the system of entry for a candidate, while the core HRIS becomes the system of record after hire. If ownership and synchronization rules are not explicit, two applications may each appear authoritative, producing conflicting values.

A sound data-governance arrangement defines:

1. the data element and its business definition;
2. the authoritative source;
3. the accountable data owner;
4. permitted users and purposes;
5. validation rules and allowable values;
6. update and synchronization frequency;
7. retention and deletion requirements;
8. correction and dispute procedures; and
9. lineage showing how data move between systems.

Data lineage is especially important in analytics. A dashboard may combine the HRIS headcount, payroll cost, and finance cost-center hierarchy. Unless definitions and effective dates are aligned, a technically accurate query can produce a misleading management conclusion.

4. Workflows, Business Rules and Auditability

A workflow is a structured sequence of tasks, decisions, approvals, notifications, and updates. A typical job-change workflow may include manager initiation, validation of required fields, HR review, compensation approval, effective-date checks, payroll notification, and audit logging.

Workflows convert policy into operational behavior. They can enforce separation of duties, ensure required approvals, route exceptions, and make process status visible. However, automation does not make a policy correct. An incorrectly designed workflow can institutionalize bias, delay urgent actions, or create excessive administrative burden.

A business rule expresses a condition or decision, such as: a salary change above a defined threshold requires additional approval; a termination cannot be finalized without a valid effective date; or an employee cannot approve their own transaction. Rules should be documented, tested with normal and exceptional cases, and reviewed when policies or laws change.

An audit trail records who performed an action, what changed, when it changed, and, where relevant, the reason and approval. Auditability supports accountability, investigation, legal defensibility, and operational troubleshooting. It should not be confused with unlimited surveillance: access to audit records must itself be controlled and justified.

5. Role-Based Access and HR Security

Role-based access control (RBAC) grants permissions according to organizational roles rather than assigning every permission to every individual. A simplified model contains users, roles, permissions, and resources. A user may hold several roles, and a role may contain multiple permissions.

Typical roles include employee, line manager, HR specialist, recruiter, payroll administrator, auditor, and system administrator. A manager may view information for direct reports but not salary details for unrelated employees. A payroll administrator may process pay but should not automatically receive unrestricted access to sensitive medical information.

Important security principles include:

• Least privilege: provide only the access needed for an approved purpose.
• Need to know: restrict sensitive information to users with a legitimate business need.
• Separation of duties: prevent one person from initiating and approving a high-risk transaction alone.
• Defense in depth: combine identity controls, encryption, monitoring, secure configuration, and staff awareness.
• Periodic review: recertify access and remove privileges when roles change or employment ends.

RBAC can be extended with attributes such as location, employment relationship, data sensitivity, or transaction amount. Attribute-based conditions are useful when a simple role is too broad, but they increase design and testing complexity.

Authentication establishes who a user is; authorization determines what that user may do. Multi-factor authentication strengthens authentication but does not correct excessive authorization. Similarly, encryption protects data in transit or at rest, but it does not make an inappropriate disclosure legitimate.

6. Architecture and Deployment Models

6.1 On-premises, hosted and cloud models

In an on-premises model, the organization owns or controls the infrastructure and is responsible for significant portions of hardware, operating systems, databases, security, backup, and upgrades. A hosted model places infrastructure in a provider facility, but the application may still be dedicated to one customer and managed under a more traditional arrangement.

Cloud computing provides on-demand access to shared configurable resources, such as computing, storage, and networking. Cloud services are commonly described as infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS). In SaaS, the provider operates the application and underlying service, while the customer configures business settings, manages users and data governance, and remains accountable for lawful and appropriate use.

Cloud responsibility is shared. The provider may secure physical facilities, platform services, and application infrastructure; the customer remains responsible for configuration, identity management, data classification, user behavior, integrations, and many compliance obligations. Contractual language should clarify backup, incident notification, subcontractors, data location, portability, deletion, service levels, and audit rights.

6.2 Multi-tenancy and availability

Many SaaS platforms are multi-tenant: multiple customers use a common software service while logical controls isolate their data and configuration. Multi-tenancy can reduce cost and accelerate updates, but it makes isolation, change management, and provider governance critical. A private or single-tenant arrangement may offer more dedicated control but can reduce economies of scale.

Availability is a service and business concern. If a platform is unavailable during payroll processing, the impact may be material. Organizations should examine service-level objectives, recovery time objectives (RTO), recovery point objectives (RPO), continuity procedures, and manual contingencies. These are not merely vendor metrics; they should be connected to HR process criticality.

7. Mobile Platforms and APIs

Mobile HR access can support self-service activities such as viewing payslips, requesting leave, approving routine actions, completing learning, and receiving alerts. Mobile design must account for small screens, intermittent connectivity, device loss, shared devices, notification privacy, accessibility, and the risk of exposing sensitive information in public settings.

A mobile application may be native, cross-platform, or browser-based. The appropriate choice depends on security requirements, device diversity, offline needs, user experience, and maintenance capacity. Mobile convenience should not lead to weaker identity controls or excessive collection of device and location data.

An application programming interface (API) is a defined mechanism through which software requests or exchanges data and functions. APIs may be synchronous, where one system requests an immediate response, or asynchronous, where an event or message is processed later. They may expose REST-style resources, GraphQL queries, or other protocols; the architectural principle is controlled interoperability, not a particular technical style.

A robust HR integration should define data ownership, field mapping, validation, authentication, authorization, error handling, retry behavior, monitoring, versioning, and reconciliation. API integration is not automatically real time, secure, or accurate. Rate limits, incomplete responses, duplicate messages, changed interfaces, and inconsistent effective dates can all create operational problems.

A practical control is reconciliation: compare the sending and receiving systems after a transfer, investigate differences, and document resolution. Sensitive HR APIs should use strong authentication, encrypted transport, minimal data scopes, logging, and explicit consent or lawful-purpose analysis where required.

8. Configuration versus Customization

Configuration changes supported settings without altering the underlying product code. Examples include defining approval thresholds, adding a permitted absence type, arranging fields, establishing organizational hierarchies, or creating a report using supported tools. Customization changes or extends the software through bespoke code, database modifications, custom modules, or unsupported alterations.

Configuration generally preserves upgrade compatibility and lowers technical debt. Customization may be justified when a legally required or strategically distinctive process cannot be met through supported capabilities. It can also create dependencies on specialist developers, complicate testing, increase security exposure, and make future upgrades expensive.

The decision should not be framed as “standard is always good” and “custom is always bad.” A process may be a genuine source of competitive or regulatory differentiation. Nevertheless, organizations should first examine process simplification, policy harmonization, supported configuration, integration, and vendor roadmap options before commissioning custom code.

A useful evaluation sequence is:

1. Clarify the business outcome and legal requirement.
2. Identify whether the current process is necessary, efficient, and consistently defined.
3. Compare standard functionality and supported configuration.
4. Assess integration or controlled external solutions.
5. Estimate lifecycle cost, security risk, upgrade impact, and exit difficulty.
6. Approve exceptions through architecture and governance review.
7. Document ownership, testing, support, and decommissioning conditions.

9. Applied Case: Northstar Manufacturing’s HRIS Renewal

This is an illustrative case. Northstar Manufacturing employs 4,800 people across three countries. Its HR department uses a legacy HR database, a separate payroll application, spreadsheets for organizational changes, and an external learning system. Managers report that headcount dashboards disagree with payroll, terminated employees sometimes retain system access, and employees cannot reliably complete transactions on mobile devices.

Background and problem

An initial technology proposal recommends replacing the legacy database with a heavily customized cloud HRIS. The proposal focuses on interface appearance but does not identify data ownership, effective dates, access roles, or integration controls. The chief human resources officer asks a cross-functional team to reassess the architecture.

Analysis

The team inventories critical data elements and discovers that the legacy HR database is the system of record for employment status, while payroll is authoritative for pay results and finance is authoritative for cost-center codes. Spreadsheets are being used as unofficial systems of entry for organizational changes. Definitions of “active employee” differ between HR and finance. Access reviews are irregular, and the termination process has no automated identity-management notification.

Approach and solution

The team adopts a domain-based governance model. Core employment and organization data will be mastered in the HRIS; payroll results remain in payroll; course completion remains in the learning system. A documented interface transfers approved changes using employee identifiers, effective dates, validation, and exception reporting. The organization standardizes the definition of active employment for each reporting purpose rather than forcing one vague definition.

The implementation uses supported configuration for approval paths, organizational security, reason codes, and mobile self-service. Only one custom extension is approved: a statutory reporting function unavailable in the vendor product. Role design separates manager, HR, payroll, and audit permissions. Termination workflow triggers an identity-access review, while a separate control verifies that access was actually removed.

Outcome

After implementation, dashboard discrepancies decline because the data lineage and definitions are explicit. Managers can initiate changes through controlled workflows rather than spreadsheets. Mobile access improves routine self-service, but sensitive documents require stronger authentication. The organization also discovers that technical implementation alone did not solve data quality: historical job and department records require a continuing stewardship process.

Learning points

The case demonstrates that HRIS renewal is an operating-model decision, not simply a software purchase. The most important design questions concern authority, definitions, controls, lifecycle cost, and accountability. It also shows why configuration, integration, security, and governance must be considered together.

10. Governance, Ethics and Contemporary Developments

HRIS data concern identifiable people and can influence employment opportunities, compensation, access, and reputation. Governance must therefore address privacy, fairness, transparency, purpose limitation, data minimization, retention, correction rights, and cross-border transfers in accordance with applicable law. Organizations should classify data by sensitivity and document legitimate purposes for collection and use.

Artificial intelligence and advanced analytics introduce additional architectural issues. A model may use HRIS data to predict turnover, recommend candidates, or flag compensation anomalies. The quality of such outputs depends on data definitions, historical bias, representativeness, feature validity, and ongoing monitoring. An AI model should not be treated as an unquestionable decision-maker merely because it is embedded in an HR platform. Human oversight, explainability appropriate to the use, impact assessment, access control, and appeal mechanisms are essential.

Contemporary HRIS ecosystems increasingly use composable architectures, event-driven integration, embedded analytics, low-code configuration, identity federation, and automated controls. These developments can improve agility, but they also create more dependencies and a larger attack surface. Each additional connector, application, and data copy requires ownership, monitoring, and lifecycle management.

Best-Practice Checklist

A graduate HR professional participating in an HRIS initiative should ask:

• What business fact is being represented, and how is it defined?
• Which system is authoritative, and who owns the data?
• Are historical and effective-dated changes preserved?
• What validations, approvals, exceptions, and audit events exist?
• Are permissions based on least privilege and periodically reviewed?
• What happens when an employee transfers, takes leave, or terminates?
• What data cross each integration, and how are failures reconciled?
• Can the requirement be met through supported configuration?
• What are the provider’s security, continuity, portability, and deletion commitments?
• How will privacy, fairness, accessibility, and employee transparency be protected?

Chapter Summary

HRIS architecture is a layered arrangement of interfaces, applications, data, integrations, security, and governance. Databases and data models determine how employee, employment, organizational, transactional, and historical information is represented. Master data provide shared entities; transactional data record events; reference data constrain classifications; and metadata explain meaning, ownership, sensitivity, and lineage.

The system-of-record concept assigns authority to a data source for a defined domain, while systems of entry initiate or capture information. Workflows and business rules translate policy into controlled sequences of action, and audit trails support accountability. Role-based access, least privilege, separation of duties, and periodic review are central security practices.

On-premises, hosted, cloud, and SaaS models distribute responsibilities differently. Cloud adoption does not eliminate customer accountability for configuration, identity, data governance, integrations, or lawful use. Mobile platforms increase accessibility but require careful treatment of authentication, privacy, device security, and usability. APIs support interoperability only when ownership, mappings, error handling, versioning, and reconciliation are designed explicitly.

Configuration usually offers better upgradeability than customization, although carefully governed customization may be justified. Effective HRIS practice therefore combines technical design with data stewardship, process analysis, ethical judgment, legal awareness, and managerial accountability.

Key Terms

API: A defined mechanism for software systems to exchange data or functions.

Audit trail: A record of actions, changes, users, times, and relevant reasons.

Authentication: Verification of a user’s identity.

Authorization: Determination of what an authenticated user may access or do.

Configuration: Supported changes to settings or behavior without altering product code.

Data lineage: Documentation of data origin, transformations, movement, and destination.

Data model: A structured representation of data entities, attributes, relationships, and constraints.

Metadata: Data that describe the meaning, structure, ownership, sensitivity, or lifecycle of other data.

Master data: Shared, relatively stable entities used across organizational processes.

Multi-tenancy: A service architecture in which multiple customers use a logically isolated shared platform.

Normalization: Relational design practice that reduces unnecessary duplication and update anomalies.

RBAC: Role-based access control, in which permissions are assigned through roles.

Reference data: Controlled codes and lists used to classify or validate information.

SaaS: Software as a service, in which a provider operates an application delivered over a network.

System of entry: The application or process in which information is first entered or initiated.

System of record: The designated authoritative source for a defined data domain or business fact.

Transactional data: Data describing events or activities such as hires, absences, or pay changes.

Workflow: A controlled sequence of tasks, decisions, approvals, notifications, and updates.

Review Questions

5 Short Answer Questions

1. What is the difference between a primary key and a foreign key?
2. Distinguish master data from transactional data and give one HR example of each.
3. Why can an organization have more than one system of record?
4. Define least privilege and separation of duties.
5. What is the principal difference between configuration and customization?

5 Long Answer Questions

1. Explain the layers of an HRIS architecture and show how weaknesses in one layer can affect the others.
2. Discuss the role of data lineage, effective dating, and data stewardship in workforce reporting.
3. Compare on-premises, hosted, and SaaS deployment models, including the distribution of responsibilities and risks.
4. Explain how workflows, business rules, and audit trails support HR governance while potentially creating new risks.
5. Evaluate the advantages and limitations of mobile HR platforms and API-based integration.

3 Analytical / Application Questions

1. An organization’s HRIS shows 10,000 active employees, while payroll shows 9,850 and finance shows 9,720. Design a diagnostic approach using systems-of-record, data definitions, effective dates, and reconciliation controls.
2. A manager requests access to all employee salaries because the manager supervises one large division. Analyze the request using RBAC, least privilege, need to know, and separation of duties. Recommend a defensible access design.
3. A vendor proposes custom code for an approval process that differs across six countries. Develop a decision framework comparing standard configuration, localization, integration, and customization. Include lifecycle, compliance, security, and upgrade considerations.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a system of record?

A. The application in which a user first types information

B. The designated authoritative source for a defined data domain

C. A backup copy stored outside the organization

D. A dashboard used by senior managers

Correct Answer: B. The designated authoritative source for a defined data domain

Question 2

Which item is most clearly an example of reference data?

A. An employee’s termination event

B. A monthly payroll result

C. A controlled list of employment-status codes

D. A performance narrative

Correct Answer: C. A controlled list of employment-status codes

Question 3

What is the primary purpose of a foreign key in a relational database?

A. To encrypt a database table

B. To identify a relationship with a record in another table

C. To calculate an employee’s salary

D. To delete duplicate records automatically

Correct Answer: B. To identify a relationship with a record in another table

Question 4

Which principle requires users to receive only the access necessary for their approved work?

A. Multi-tenancy

B. Least privilege

C. Normalization

D. Data portability

Correct Answer: B. Least privilege

Question 5

Which statement about SaaS is most accurate?

A. The customer has no responsibility for security or data governance

B. The provider operates the application, while responsibilities remain shared

C. The customer must own all physical servers

D. SaaS cannot support APIs or mobile access

Correct Answer: B. The provider operates the application, while responsibilities remain shared

Question 6

What is a major advantage of configuration over customization?

A. It always eliminates the need for testing

B. It generally preserves compatibility with supported upgrades

C. It permits unrestricted changes to product source code

D. It removes the need for data governance

Correct Answer: B. It generally preserves compatibility with supported upgrades

Question 7

Which control is most directly concerned with comparing data after an interface transfer?

A. Reconciliation

B. Normalization

C. Authentication

D. User-interface design

Correct Answer: A. Reconciliation

Question 8

A workflow that prevents one person from both initiating and approving a high-risk transaction applies which principle?

A. Separation of duties

B. Data minimization

C. Multi-tenancy

D. Denormalization

Correct Answer: A. Separation of duties

Question 9

Which statement best distinguishes authentication from authorization?

A. Authentication determines permissions; authorization verifies identity

B. Authentication verifies identity; authorization determines permissions

C. Both terms mean database normalization

D. Authentication applies only to mobile applications

Correct Answer: B. Authentication verifies identity; authorization determines permissions

Question 10

An HR report contains 950 populated required fields out of 1,000 expected fields. Using the completeness formula in the chapter, what is the completeness rate?

A. 5%

B. 50%

C. 95%

D. 105%

Correct Answer: C. 95%