ERP and HR

The engine reads organisation, job and ledger records from SAP S/4HANA, SAP SuccessFactors and Workday into a knowledge base, for finance, supply and workforce planning agents.

Content is read in place, in your deployment, in your own account. LightHouse receives ids, hashes and counts only. It does not receive the records, and it does not open the credential.

Read-only

These connectors only read. Read and write is refused (422 read_only_connector) in the API, in LightHouse and in the CLI, and the engine refuses it as well. Connect them as Read. The deployment makes GET requests only.

What is left out

No object these connectors read in this release holds the records below. As a final guard, the deployment also drops every field and report column whose name matches its personal-data deny-list, and records only how many it dropped (dropped_columns).

Connector	Left out
SAP S/4HANA	Individuals’ records (business partners who are people, employees, contacts, addresses); payroll and employee cost postings; bank details and tax ids
SAP SuccessFactors, Workday	Employee records (names, national ids, dates of birth, home addresses); pay and benefits (compensation, payroll, bank details, tax ids); health, disability and diversity data; performance and disciplinary records

Connect in LightHouse

Requires the Client administrator (client_admin) role, signed in as a person, and a deployment whose engine reads this connector (compatibility reference) and keeps credentials in your own store.

1. Create the client or user at the provider, as described for each provider below.
2. Go to Setup and admin → Connectors, find the provider (search for it, or filter by family), and choose Connect.
3. Enter the fields listed for the provider, and leave the access level at Read.
4. Paste the credential. Your browser seals it to your deployment’s key; LightHouse does not see it.
5. Your deployment stores the credential and checks it. The card shows the result of the check.

The same connection can be made with lighthouse-ai connect <provider> --credential-stdin, which seals the credential on your machine.

What the health codes mean

Code	Meaning	Action
ok	The credential signs in and reads	None
auth_failed	The provider refused the credential	Create a new client or user, or a new refresh token, and connect again
unreachable	The API host or token host did not answer	Check the host names and your deployment’s outbound access to them
scope_missing	The client or user lacks read on the service the check uses	Grant read on the services listed for the provider, and connect again

SAP S/4HANA

• Reads: sales and purchase orders, supplier invoices, material documents, products, journal entries, cost centres and organisations, through SAP’s released OData services.
• Create: a communication arrangement in S/4HANA with read-only OData services, signed in either by an OAuth 2.0 client (client credentials) or by a communication user (HTTP Basic).
• Paste: two lines. For OAuth, the client ID, then its secret. For a communication user, the user, then its password.
• Name: Your S/4HANA API host (https://<host>), How it signs in (OAuth 2.0 client, the default, or communication user), Token URL (OAuth only) and What to read: any of sales_orders, purchase_orders, supplier_invoices, material_documents, products, journal_entries, cost_centres and business_partners (organisations only).
• Hosts contacted: the API host, and the token host where there is one. Redirects are not followed.

SAP SuccessFactors

• Reads: departments, locations, job codes, positions and job requisitions. Employee records and pay are not read.
• Create: an OAuth 2.0 client (client credentials) registered in your SuccessFactors tenant, with read on the organisation and recruiting objects only. SAML bearer and HTTP Basic are not supported.
• Paste: two lines: the client ID, then its secret.
• Name: Your API host (your data centre’s API host, such as https://api4.successfactors.com), Company ID, Token URL and What to read: any of departments, locations, job_codes, positions and job_requisitions.

Workday

• Reads: supervisory and cost-centre organisations, job profiles, locations, job requisitions, and the reports you name. Workers and pay are not read.
• Create: an API Client for Integrations with a refresh token, limited to the organisation and recruiting functional areas and to the reports you share with it.
• Paste: three lines: the client ID, its secret, then the refresh token.
• Name: Your Workday host (*.workday.com or *.myworkday.com, without https://), Tenant, What to read (any of organisations, job_profiles, locations and job_requisitions) and Reports (owner/report, comma separated, up to 20). Report columns whose names match personal data are dropped and counted.

Where the credential is held

LightHouse does not open these credentials. They are sealed in your browser, or by lighthouse-ai connect <provider> --credential-stdin, to your deployment’s own key, and your deployment keeps them in your own secrets store. LightHouse keeps the connection’s fingerprint, the access level, the time of the last check and its code. It does not keep the credential or the records read. See Where every credential is held.

Removing it

On the card, choose Disconnect. Your deployment deletes the credential from your store. Revoke the client, user or refresh token at the provider as well. Documents already written stay in the knowledge base until you delete them.

The collectors behind these connectors are in the collectors catalogue, with their certification status.