Oracle Fusion Cloud and Workday

How to connect Oracle Fusion Cloud (ERP, SCM and HCM) and Workday. Both read, and both can also make changes once a SourceLace admin turns them on: Oracle Fusion creates and updates records, and Workday starts one business process, the business title change (see Making changes). Each person signs in with their own Oracle or Workday login, so Oracle and Workday show them only what their own roles and security groups allow. SourceLace never uses an administrator or integration system account, for reads or for changes.

Status: in testing. Built against Oracle's and Workday's documented REST APIs and covered by automated tests against simulated systems; not yet used with a customer's live Oracle pod or Workday tenant.

How this differs from other sources

There is no SourceLace-wide app for Oracle or Workday. Your Oracle or Workday admin registers an OAuth client for SourceLace inside your own system, and your SourceLace admin types its details into the source.

• The client secret is stored encrypted with your organization's own key. After saving, SourceLace only ever shows (saved). To keep it when editing the source, leave the field empty; to change it, type the new one.
• Type the secret on the web app's Manage sources page, not in a chat, so it never sits in a chat transcript.
• SourceLace sends a PKCE challenge with every sign-in. A public client (no secret) also works where your policy prefers it: leave the secret empty.

The redirect URL both systems ask for is:

https://sourcelace.onrender.com/connect/callback

Oracle Fusion Cloud

Register SourceLace (Oracle identity domain administrator, about 15 minutes)

You need the Identity Domain Administrator role for the identity domain your Fusion users sign in with.

1. Sign in to the OCI Console (cloud.oracle.com). Open Identity & Security → Domains and click the identity domain your Fusion users sign in with. (Older pods call this Oracle Identity Cloud Service; the steps are the same.)
2. On the domain's Overview, copy the Domain URL, such as https://idcs-0123456789abcdef.identity.oraclecloud.com. This is the idcs_url option.
3. Open Integrated applications → Add application → Confidential Application → Launch workflow. Name: SourceLace. Click Next.
4. Under Client configuration, choose Configure this application as a client now:
   • Allowed grant types: tick Authorization code and Refresh token, nothing else.
   • Redirect URL: the redirect URL above.
   • Client type: Confidential.
   • Token issuance policy → Resources: tick Add resources, click Add scope, choose your pod's Fusion Applications resource, and add its scope (usually urn:opc:resource:consumer::all).
   • Click Next, then Finish.
5. Click Activate on the new application.
6. On its OAuth configuration tab, copy the Client ID, the Client secret (Show secret), and the scope shown next to the Fusion resource, exactly as shown with no added spaces, such as urn:opc:resource:fa:instanceid=123456789urn:opc:resource:consumer::all. SourceLace adds offline_access itself, so people stay signed in.
7. Note the address people use for Fusion, such as corvanta.fa.us2.oraclecloud.com. This is the host option.

Add the source (SourceLace admin)

Kind: Oracle Fusion Cloud (ERP, SCM, HCM) (oracle_fusion).

What people can do

• search_schema lists common resources (Payables invoices, suppliers, purchase orders, requisitions, sales orders, items, projects, and HCM workers, absences, jobs and positions) plus any in resources. Any other Fusion REST resource can still be queried by name.
• describe_object reads the resource's own description from Oracle: its attributes and child resources.
• query (language fusion_rest) takes a resource with Oracle's REST options, such as invoices?q=InvoiceAmount > 1000 and PaymentStatusFlag = 'N'&fields=InvoiceId,InvoiceNumber,InvoiceAmount&orderBy=InvoiceDate:desc&limit=50. HCM resources start with hcm/ and CX ones with crm/. The options allowed are q, fields, orderBy, finder, expand, limit (up to 500) and offset; anything else is refused before Oracle is called. SourceLace pages through results itself.
• get_record reads one record by its key, plus up to three child resources (such as an invoice's invoiceLines).
• propose_change and apply_change create and update records, when changes are on (see Making changes).

Workday

Register SourceLace (Workday security administrator, about 15 minutes)

You need someone who can run the Register API Client task. Try it first in an implementation or sandbox tenant.

1. Search for the task Register API Client (not "for Integrations": that one is for system accounts, and SourceLace signs each person in with their own login).
2. Fill it in:
   • Client Name: SourceLace.
   • Client Grant Type: Authorization Code Grant. Access Token Type: Bearer.
   • Redirection URI: the redirect URL above.
   • Refresh Token Timeout (in days): how long people stay connected, such as 30, or tick Non-Expiring Refresh Tokens if your policy allows.
   • Support Proof Key for Code Exchange (PKCE): tick it if your tenant shows it.
   • Leave Public Client unticked.
   • Scope (Functional Areas): at least Staffing, Organizations and Roles, Time Off and Leave, Jobs and Positions, Contact Information and System (System holds Workday Query Language). Add others, such as Compensation or Benefits, for data people should read.
   • Include Workday Owned Scope: tick it.
3. Click OK. Workday shows the Client ID and Client Secret once: copy both now.
4. Search for View API Clients and open the API Clients tab. Copy:
   • Workday REST API Endpoint, such as https://wd2-impl-services1.workday.com/ccx/api/v1/corvanta_preview. Its host (wd2-impl-services1.workday.com) is the host option, and its last part (corvanta_preview) is the tenant option.
   • Authorization Endpoint, such as https://impl.workday.com/corvanta_preview/authorize. If its host differs from the REST API host, that host (impl.workday.com) is the auth_host option.

Add the source (SourceLace admin)

Kind: Workday (workday).

What people can do

• search_schema lists the REST objects (workers, supervisory organizations, job profiles, job families, jobs) and the WQL data sources the person may use (such as allActiveWorkers).
• describe_object on a WQL data source lists its fields; on a REST object it lists the fields of a sample record and the related lists get_record can add.
• query takes wql, one Workday Query Language SELECT ... FROM ... such as SELECT workdayID, fullName, businessTitle FROM allActiveWorkers WHERE isManager = true (no LIMIT needed), or workday_rest, a REST collection with search, limit and offset, such as workers?search=Lee&limit=20.
• get_record reads one REST object by its Workday ID, plus related lists such as a worker's directReports, supervisoryOrganizationsManaged or timeOffDetails.
• propose_change and apply_change start a business title change, when changes are on (see Making changes).

Making changes

Changes are off until a SourceLace admin turns on Allow changes for the source and lists the objects under Objects that can be changed (such as invoices for Oracle Fusion, or businessTitleChange for Workday). As everywhere in SourceLace, the person first sees a preview with the current and new values, and nothing is sent until they confirm. Each change runs as that person's own Oracle or Workday login, so their own roles decide whether it is allowed.

Oracle Fusion: create and update

• What can be changed: any top-level Fusion REST resource the admin lists, by the same name query uses (such as invoices, suppliers, purchaseRequisitions or hcm/workers). A create sends one new record to the resource; an update changes one record.
• Checked before anything is sent: field names are checked against the resource's own description from Oracle. An unknown field, or one Oracle marks as not updatable, is refused in the preview. If Oracle says the resource does not allow create or update, that is refused too.
• The preview shows the record's current values of just the fields being changed.
• If someone else changed the record after the preview, the change is refused and the person is asked to propose it again. SourceLace uses Oracle's record version (ETag) when Oracle returns one; otherwise it compares the record's LastUpdateDate (or, if the resource has none, the values themselves) just before writing.
• Deletes are refused. Fusion records are closed or cancelled through their status (for example, cancel an invoice or close a purchase order), so ask for a status change instead.
• What each person's roles decide: whether they can create or change that kind of record at all (their Fusion duty roles and privileges, such as Manage Payables Invoices) and which records (their data security, such as business units). If Oracle refuses, SourceLace shows Oracle's own message.
• Setup: nothing new. The Fusion scope you already gave the OAuth client covers reads and changes; Fusion's roles are what limit changes. Make sure the people who should make changes have the right Fusion roles.

Workday: the business title change

Workday does not let outside apps edit records directly: every change runs a business process inside Workday, with its own approvals. SourceLace only offers changes that are a single, documented Workday REST call, so a change can never stop half way. Today that is one:

• It is proposed as an update, with object businessTitleChange and the worker's Workday ID as the record id. The preview shows the worker's current business title.
• Approvals still apply. The preview says so: this starts Workday's own business process, so if your Workday setup requires a manager or HR partner to approve, the new title shows only after they do.
• Creates, deletes, any other field and any other Workday object are refused in the preview, before anything is sent. Just before starting the change, SourceLace reads the worker's current title again and refuses the change if it moved since the preview.
• Once changes are on, search_schema lists businessTitleChange and describe_object shows its field.
• What each person's security groups decide: whether they may start a business title change for that worker, set by the business process security policy for Business Title Change in Workday (for example, workers for themselves, or managers for their team). If Workday refuses, SourceLace shows Workday's own message.
• Setup: the API client's scope must include Staffing, the functional area that holds the Business Title Change business process (already in the list in step 2 above). If your API client was registered without it, edit the client in View API Clients and add it. Then turn on changes for businessTitleChange on the source.
• Not offered yet: contact information changes, job changes, time off and other business processes.

When something goes wrong