You are on page 1of 13

CS HCM Integration

FAQ
May 2010
Document Purpose
The purpose of this document is to ensure that our Customers, as well as the Oracle Field, Support,
Consulting and Strategy teams understand the CS-HCM integration effort for the Higher Ed customer base.
We want to communicate at least three major considerations about the HCM CS Integration:

There is a continuum of options for customers to achieve this integration, including direct integration
as well as use of the Higher Education Constituent Hub
Most of the tools the customer needs to achieve the integration are available now; enhancements
nd
are targeted for 2 half 2010
Customers dont need to complete the separation (and integration) until they want to upgrade to
HCM 9.1

Oracle plans to update this document as customers deploy the integration functionality and we find useful
information to share. Please see this My Oracle Support Knowledge page for more information

(Document ID 1259484.1 Feature Pack 4 in Bundle 19 for CS 9.0.)


Overview
1. What is happening with the CS HCM separation?
A: HCM 9.0 contains the CS 9.0 and HRMS 9.0 applications, in a shared instance of the database. As a
result of the Campus Solutions Continuous Delivery Model, introduced in 2009, Campus Solutions will not
have a 9.1 release; new functionality will instead be released incrementally through Feature Packs. Since
HRMS will upgrade to 9.1 but CS will not, Oracle needs to provide a way for customers to maintain the data
relationships between CS 9.0 and HRMS 9.1. To do this, PeopleSoft HCM and CS Development will deliver
objects to provide supported integration between the two instances.
2. What are these changes?
A: Campus Solutions is not part of the HCM 9.1 upgrade. Campus Solutions will remain on the 9.0
codeline, delivering new functionality through Feature Packs in the maintenance stream. When customers
upgrade to HCM 9.1, they will need to clone their HCM/CS 9.0 instance, upgrade one instance to HCM 9.1
and maintain the second instance for CS 9.0. Oracle will deliver supported integration for core Person data
between CS 9.0 and HCM 9.0 or HCM 9.1. Customers will have options for the integration they want to
deploy, from full bi-directional support to syncing the Emplid only.
3. When will customers be required to move to separate instances?
A: Customers will be required to move to separate instances of CS 9.0 and HCM 9.1 when they upgrade to
HCM 9.1. There is no CS 9.1 release. Customers may choose to separate the HCM 9.0 instance and
integrate CS 9.0 with HCM 9.0, but this is not required. HCM 9.0 is covered by Premier Support through
Dec 2011, Regulatory, Legal and Tax updates through Dec 2012 and Extended Support available through
Dec 2014. Note that Oracle will waive the Extended Support Fee for 12 months, which extends coverage
with no extra fee, through December 2012 (announced at Oracle Open World, Sept 2010).
4. Why is Oracle separating CS from HCM?
A: Customer input starting with early releases of Campus Solutions suggested that the cost of upgrades
and lock-step maintenance with HCM was outweighing the benefit of receiving new functionality in that
upgrade. Therefore, Campus Solutions adopted a Continuous Delivery Model in 2009, taking it out of the
upgrade stream for the PeopleSoft 9.1 releases.

HCM - CS Integration FAQ Nov 2, 2010

Page 1 of 13

5. What resources are available to assist customers with the integration?


A: Oracle has provided a number of Integration Guides, recorded TOIs and Peoplebook updates which are
available on this My Oracle Support Knowledge page.
6.

What skills should customers assume they need to have on campus to manage this
new integration?
A: See the Learning Path for Campus Solutions IT job role on the OU website. CS Development is making
efforts to provide straightforward documentation to help bridge skill gaps for the direct integration.
However, we recommend you review the Learning Path information. We will work with the TAG and the
newly-formed Feature Pack Focus Group to provide advice to the customer community about skills needed.
7. What new products will my institution need to purchase to support this integration?
A: None. The enhancements to support the direct integration approach, outlined below, are provided as
part of HCM and CS maintenance, beginning with October 2010 HCM bundles and a CS 9.0 Feature Pack.
Customers will have the option of licensing middleware to support more sophisticated integration scenarios.
Similarly, customers who have the need to govern the exchange of Person Data between multiple systems
on campus may evaluate the Master Data Management solution for Higher Education, the Higher Education
Constituent Hub.
8. Can Oracle provide hardware/OS Level/DBMS level recommendations?
A: Please refer to the current Hardware/Software Guidelines for HCM 9.0 available in My Oracle Support.
There are no additional recommendations relevant to the separate instances.

Section I: Core Information


9. What options do customers have for this integration? What are the approaches Oracle
will support?
A: Oracle delivers a toolset that allows customers flexibility in implementing the pieces in a way that best
meets their particular business processes. Four configurations are documented as models to help customers
understand how the tools can be deployed:
1. Bi-directional support via the Higher Education Constituent Hub. The governance rules in
the hub determine which application(s) can master the bio/demo data and which are
subscribers to updates from changes in the hub. The hub assigns the Universal ID to a
person and then masters the emplid value from both CS and HCM.
2. Direct integration between CS and HCM, with an Owner/Subscriber approach (CS is the
owner of the Personal data, which is messaged to HCM for the Hire activity and ongoing
personal data maintenance). All persons are recorded in BOTH instances, replicating the
functionality in the shared instance. Any activity which adds a new person to the CS or
HCM database will initiate in the Campus Solutions instance. Messaging will then move the
new person record to the HCM instance.
3. Subscriber Only approach in which core Person bio demo data can flow in both directions
between CS and HCM. Persons can be created and updated in either system and the data
will be synchronized to the other system.
4. Distinct Ownership approach in which HCM and CS maintain separate records for
individuals personal data. The customer can use the External S/M functionality to sync the
Emplid upon creation in either the HCM instance or the CS instance.
10. What data is kept in sync for these options?
A: See the Setup EIP and the Person Integration Guides for the message content. The specific pieces of
data kept in sync vary based on which approach the customer takes. The supported messages include
Bio/Demo data (e.g., Name, Address, Contact info, etc.) and the shared set up tables (e.g., Country,
Location, etc.). Customers will evaluate the messages and decide which they want to deploy.

HCM - CS Integration FAQ Nov 2, 2010

Page 2 of 13

11. What data elements and utilities are unique to Campus Solutions and as such, will not
be integrated with HCM?
A: The focus of the first phase of CS-HCM integration is on high value business processes where shared
data is important. Therefore, the first phase of the integration support covers the high priority data
elements, based on customer input. As customers begin to leverage the integration, Oracle will respond to
enhancement requests for additional data. Customers should also be aware that there are a number of
Campus Solutions utilities that are not supported in the HCM application; these include the use of 3Cs,
Population Selection/Update, Service Indicators, and Campus Self Service. Additionally, there are some
data elements that exist only in Campus Solutions and therefore there is no reason to include them in the
messages that update HCM (the fields do not exist in the HCM application). These include External System
ID, Campus ID, FERPA, and External Organizations.
12. Which business processes are impacted by the integration?
A: This depends on the tools and configuration implemented. To varying degrees, the Hire process
(including Recruiting) as well as maintenance of Bio/Demo data for individuals (the data commonly
considered part of Campus Community) could be impacted. The bio/demo data (and limited Job Data) for
Instructors/Advisors will be in Campus Solutions to support business flows that require that information.
Likewise, student bio/demo data will reside in the HCM instance, available should a student become a
student worker. The institution will need to assess how they handle the Student Refunding process;
Accounts Payable is the preferred solution but customers may use the Payroll application within the CS
instance. Customers using Payroll within the CS instance will need to apply appropriate Payroll
maintenance. This solution is limited by the fact that Payroll will stop delivering Tax Updates on HCM 9.0
when support for this release ends (December 2014).
13. Two of the models (e.g, owner / subscriber and distinct ownership) appear to be at
opposite ends of the spectrum of supported integration. Are there additional points inbetween customers should consider?
A: The concept of a school syncing SOME of the bio-demo data fields, such as Name, Address or email
address is a point along the continuum that some schools may want to consider. Syncing only some of the
setup tables is another option; we expect these requirements to vary by customer. Another approach
customers might choose to take would be to do full person bio-demo data (data in the Person Basic Sync
message), but not syncing any other person data (Visa/Permits, Citizenship, Ethnicity, etc.). Yet another
example would be whether Job data is synced.
14. What is the Higher Education Constituent Hub?
A: Oracle has released a Higher Education-specific version of the Siebel UCM data hub, called the "Higher
Education Constituent Hub" (HECH). This data hub solution was designed with Higher Ed customers in mind
and contains updates to attributes, labeling and so on to better fit the Higher Ed industry requirements. It
is available today for institutions that want to deploy a data hub to connect campus systems together,
including HCM and Campus Solutions.
15. Is there delivered integration between the HECH and Campus Solutions?
A: Campus Solutions has already released (in Feature Pack 1 for CS 9.0) the Constituent Web Service and
External Search/Match, which were built to support the integration of core person data between Campus
Solutions 9.0 and other campus systems, including the Higher Ed Constituent Hub. The enhancements
planned for Feature Pack 4 will include a suite of service operations and transformations specific to
integration with the HECH. The customer will need to configure and develop aspects of the HECH product
to complete the integration and they will need to "wire" the two systems together but they have all the
basic pieces they need to do that.
16. Is there delivered integration between the HECH and PSoft HCM 9.1?
A: There is no delivered integration that provides out of the box support between HECH and other
PeopleSoft (or EBusiness) applications. However, Oracle is providing enhancements to CS 9.0 and HCM 9.1

HCM - CS Integration FAQ Nov 2, 2010

Page 3 of 13

to facilitate the customers efforts to integrate HECH with those two applications (e.g., HCM has enhanced
Person_Basic_Sync and added support for External S/M). Note that the FP4 CS objects referenced in the
above answer are not usable by HCM.
17. Do Upgrade scripts need to be revised to accommodate the instance separation?
A: No. Customers will continue to use the HCM 9.0 to HCM 9.1 upgrade scripts, which do not contain any
Campus Solutions scripts.
18. What does Oracle recommend with respect to the HR objects in CS instance and vice
versa?
A: In this first phase, Oracle will not be providing automation to remove any objects or data. Oracles
long-term goal is to have an instance of CS that does not contain the HRMS structures (and vice versa).
Each customer will be responsible to remove the person data that is no longer needed in each instance.
The HCM Strategy team reports there should be no legal issue with having Payroll data residing in the CS
instance, but they caveat that this is not a legally-informed position and the customers should research
what their data maintenance policies are.
19. What is the path for a HCM 8.9 customer to move to the separate instance?
A: There is no supported upgrade path that automatically moves a customer from HCM 8.9 to a separate
instance of CS 9.0 and HCM 9.1. The supported path is to upgrade HCM/CS 8.9 to HCM/CS 9.0, then to
deploy separate instances, and finally to upgrade to HCM 9.1.
20. How will the functionality supporting the integrations be delivered?
A: Oracle will deliver the new functionality as part of a Feature Pack (for CS) or a bundle (for HCM). The
first phase of support will be delivered in CS 9.0 Feature Pack 4 (with Bundle 19) and with HCM 9.0 Bundle
14 or HCM 9.1 Bundle 3. Additional capabilities will be delivered in subsequent HCM and CS maintenance.
21. What does Oracle recommend doing first; 9.0 upgrade or separating CS and HCM?
A: Since the supported integration is between CS 9.0 and HCM 9.0 or HCM 9.1, Oracle recommends
customers upgrade from HCM 8.9 to HCM 9.0 in a combined instance, and then clone and separate the
instances. Depending on specific circumstances, it may be more efficient in time or resources to upgrade
HCM 8.9 directly to HCM 9.1. Each institution should examine their own plans, resources, and timeframes
to make their final decision.

Section II: Messaging Infrastructure


22. Which messages will be used in the integration? Which versions of the delivered HCM
messages (Person_Basic_Sync, Workforce_Sync, Constituent Web Service) will be
used?
A: Please see the Person Data Integration Guide documentation. This document includes an Appendix
listing the service operations.
23. Is Middleware required to manage this integration?
A: No. The direct integration approach is point-to-point, using PeopleSofts Integration Broker. The
customer may choose to use middleware (e.g., BPEL) to facilitate more complex integration scenarios (e.g.,
multiple CS instances to a single HCM system).
24. Are we going to deliver Full Sync for Person_Basic_Sync (PBS)?
A: Please see the Person Data Integration Guide documentation.
25. Does Workforce Sync work in the integration?
A: Please see the Person Data Integration Guide documentation.

HCM - CS Integration FAQ Nov 2, 2010

Page 4 of 13

26. To what extent will Oracle deliver service operations that are pre-packaged and
implemented in Campus Solution and HCM for the integration? To what extent will the
institution be required to do development and/or configuration?
A: Oracle will deliver a solution that is as pre-packaged as Integration Broker allows. All the integrations
in scope are planned to use delivered Service Operations, using typical Integration Broker configuration
tasks. Aside from the actual database activities related to an HCM 9.1 upgrade or HRCS 9.0 database
cloning, customers will need to complete the typical configuration tasks to setup Gateways, Nodes, Queues,
and then activate the appropriate Integration Broker settings for all Service Operations they plan to
implement. As an example, for a full Owner/Subscriber model configuration (syncing all Setup and Person
data) we plan about 50 different integrations that will require configuring. We will issue Integration Guides
with the release of the enhanced messages that will document the configuration tasks, and which will
provide implementation guidance.
27. Is the Constituent Web Service (delivered in Feature Pack 1) used as a part of the
solution for integrating independent instances? If so, how?
A: The CWS is used in the integration with the Higher Ed Constituent Hub solution. It is not anticipated for
use (and will not be documented as part of our best practice in our Integration Guide) for direct CS-HCM
integration, because of the nature of the CWS and the fact that this message structure doesnt exist in HCM.
The Constituent Web Service (CWS) starts by subscribing to PERSON_BASIC_SYNC, then enriches it with
attributes from the PERSON_SA table, and further enriches it with AFFILIATIONS data. Because
PERSON_SA and AFFILIATIONS are CS-specific, using CWS as the exposure of CS-side data means
publishing CWS (PBS+PERSON_SA+AFFILIATIONS) then, in the subscription handler on the HCM side,
stripping out PERSON_SA and AFFILIATIONS data! Therefore, for direct integration, we are documenting a
best practice of using PERSON_BASIC_SYNC as the integration message between the systems.
28. How is person messaging triggered? What does near real-time mean??
A: We are deploying standard asynchronous messaging, commonly known as Publish/Fire and Forget.
Campus Solutions components publish the message and the HCM application will subscribe to the message.
Asynchronous means that this type of message interaction is not synchronous; synchronous means that
you save a change to a component and have to wait for a response from HCM that that system has
received the message. The delivered solution uses asynchronous messaging because we didnt want the
integration to be dependent on a tightly coupled relationship between HCM and CS. Asynchronous
messaging allows the HCM application to be down while updates continue to be made in CS. In
asynchronous messaging, the published message may take less than a second or, depending on traffic,
may take a few seconds or more. Example for the Hire business process: the process needs to start with a
CS page to add core person data. Once the user saves the page where he has added core person data, the
message is fired. The newly assigned Emplid appears at top of the CS page. At that point, the user moves
to the HCM page to complete the Hire process (adding Employment and Job data). The user will need to
specify the new Emplid in the HCM page and can then access the information that was just saved in the CS
instance the HCM instance has subscribed to the message so that data is available.
29. Will the Job, Position and the earnings tables be synched up from HCM to CS?
A: The new approach has core bio-demo person data added in CS and synced to HCM. However, the Job
information is passed from HCM to Campus Solutions via the Workforce_Sync message. The Earnings Table
synchronization may be added to the integration if Oracle adds support for Federal Work-Study. If a
customer needs to use the Earnings values within the CS application, they will configure the integration
points to subscribe to that data. We will describe this available integration in our documentation.
30. Will Prospects continue to be a part of the HCM database, as they are today in the
shared instance? Is there a supported approach that allows an institution to maintain
their Prospects in CRM, but not in the HCM instance?
A: In the Owner/Subscriber or Subscriber Only models, all prospect data loaded to CS is messaged to HCM.
In phase 1,, we are not delivering the capability to limit or filter the records sent over to HCM. We know

HCM - CS Integration FAQ Nov 2, 2010

Page 5 of 13

this type of filtering is desired by some customers and we are interested in evaluating those options with
customers for a later phase. In the Distinct Ownership approach, prospects data stays in CS only.
If a customer is using PS CRM to store and manage prospects, the best practice is to maintain the prospect
data only in CRM. Once the person becomes an applicant in the CS Admissions module, the applicant data
will be messaged to HCM, if the customer is using the Owner/Subscriber model.
31. Will EmplIDs be created in HCM as a result of Campus Solutions batch loads of data
(e.g., applicants through test score loads)?
A: Yes, this is the case if the customer is deploying using a Owner/Subscriber or Subscriber Only approach
of direct integration. All Campus Solutions batch loads (prospect load, test scores, ISIR, TAC, etc) all
invoke a service or process that can publish the Person_Basic_Sync message. How that happens can vary
depending on the program - App Engine programs (like prospect loads) invoke certain services, legacy
Cobol/SQR (lSIR) invoke a batch publish process, etc. For example, the TS189 (SQR) process cannot
invoke a web service directly. But the TS189 process is delivered with a process that does publish PBS. This
Batch Publish process was delivered in 8.9, and was implemented in all delivered CS legacy SQR/Cobol
programs. Many customers have not been in practice of using it there have been no business requirements
to deploy the messaging infrastructure.
Customers who deploy the Distinct Owner approach are not sync'ing Person data, and we don't expect
them to use PBS between the CS and HCM instances.
32. On the HR side, are there any batch loads of recruits or employees into HCM that will
be handled in this integration?
A: There is a US Federal process that batch creates persons in HR, but US Federal support is out of scope
now. There are some processes tied to personal data updates, e.g., running personal data refresh to
update future-dated addresses to the personal data snapshot table. We are recommending revised
business processes that will have users perform those Person data updates in the CS instance instead of
HCM. As noted earlier, the Person_Basic_Sync message will publish from CS to HCM and updates will be
synchronized in both instances that way.

33. What special considerations are there for batch programs, especially those that create
identities in Campus Solutions or HCM? Do an institutions custom batch load
programs need to be modified to invoke the web services in order for the integration to
be properly handled?
A: Yes. For the Owner/Subscriber and Subscriber Only models we expect Person data to be integrated
from CS to HCM. Delivered CS batch programs already integrate with the appropriate web services for
publishing person data. For example, the SAD_TEST_PST (the Admissions Test Score Search/Match/Post
app engine program) will publish PERSON_BASIC_SYNC as part of creating or updating data. Similarly, in a
Subscriber Only configuration, the customer will need to publish any Persons newly created by batch
programs in HCM to CS. The customer will need to modify their custom programs to ensure they are
invoking the right services to send the data to HCM or CS. Publishing PBS is already a requirement for
anyone who has deployed the Constituent Web Services.
For the Distinct Ownership model we dont expect Person data to be synchronized between the databases
(except when establishing the EMPLID, at time of initial Person create, using External Search/Match.) Note
that in Phase 1 of the CS-HCM integration, External S/M is invoked with online updates, but not batch
updates.
34. Can we get some guidance on how to modify our custom processes to work with the
integration?
A: First, lets review some background on what is provided by Oracle for batch updates within Campus
Solutions. For SQR and COBOL processes, updates happen directly at the table level, but an additional
insert is made to an auxiliary table that is used to trigger a Person_Basic_Synch message (by an app

HCM - CS Integration FAQ Nov 2, 2010

Page 6 of 13

engine process). There is also a variant of this for some higher volume loads that leverage something
called CS_PERSON_SERVICE, but it in turns fires Person_Basic_Sync.
The result is that all delivered batch updates will have information flow through Person_Basic_Sync and
thus keep separate instances informed (depending upon the type of instance separation). So, the delivered
updates are covered, but any customizations or additional processes created by customers would have to
be reviewed. Documentation delivered in support of the CS-HCM Instance Separation will include details to
assist you in analyzing the options available to allow custom bulk load processes to fire Person_Basic_Sync.

Section III: Impact on Customers


35. How will my institution learn about the instance separation?
A: Customers can see a description of the change in the annual Campus Solutions Statement of Direction
FY2011, published in July 2010. Then, they can review the Release Value Proposition update, published
shortly before the enhancements are released in the Feature Pack. Finally, they will have the PeopleBooks
updates that accompany the Feature Pack; the major source of documentation will be contained in the
Integration Guides that will outline how to use the messages and utilities provided with the Feature Pack.
36. Is Oracle providing recommendations on what new hardware is required to support the
separate instances and integration?
A: We are planning to engage with the HEUGs Technical Advisory Group and other customers to help with
recommendations.
37. What impact does this separation have on the normal CS maintenance cycle?
A: No change to the CS maintenance cycle is anticipated.

38. Will this new integration affect any other Oracle/PSFT applications or just HCM?
A: Other integrations between CS and PSFT FMS, PS CRM and EBusiness GL remain the same. Only the
HCM interaction is impacted. However, in a future Feature Pack, we plan to introduce enhancements to the
integration with PSFT Accounts Payable to support student refunding. See Question #49 for some specifics
around integration with PSFT Financials.
39. How will the Hire Process be impacted?
A: The impact will be outlined in the CS-HCM Integration White Paper. The impact is different depending
on the configuration that is modeled. For the Distinct Owner model, the users will maintain the persons
data in the application that is managing that person (e.g., HRMS for employees, CS for students/alumni).
You will use External S/M as part of the Add Person activity to determine if a person already exists in the
other database. If that person does exist already, External S/M will facilitate the ability to import the
existing EMPLID and personal data into the new instance and then continue with the add (hire) activity.
For the Owner/Subscriber approach, all persons must be added in CS first, regardless of if youre adding a
prospect, an alumni, an applicant who is going through the Hire process or a Hire without using Recruiting.
Navigation can be consolidated in the application portal to streamline the process of using the CS
component to Add Person and then completing the transaction in the HCM instance.
For the Subscriber Only approach, the Hire process can be utilized as currently delivered, and the core
Person bio-demo data for the new hire will be messaged to the CS instance.
For the HECH approach, users will maintain the data in the respective instance; the HECH will create the
mapping of the Emplid(s).
40. How will HCM Recruiting be impacted?
A: See the answer related to the Hire process. For the Distinct Owner approach, you will use External S/M
to determine if the applicant has a record in the CS instance and use the Import feature to bring their

HCM - CS Integration FAQ Nov 2, 2010

Page 7 of 13

EMPLID and core bio-demo data into the HCM instance. For the Subscriber Only approach, recruiting
processes can be utilized as currently delivered, and the core Person bio-demo data will be messaged to
the CS instance. For the Owner/Subscriber approach, when an applicant is ready to move through the Hire
process, he/she must first be added to the CS instance as a Person, establishing an EMPLID and core biodemo data. Then the Hire process is completed in HCM. We anticipate working with customers, post the
first phase of this deliverable, to streamline the data entry flow.
41. How will updates to employee and/or student bio-demo data be impacted? What
about self-service updates to personal data?
A: For the Distinct Owner approach, data will be updated in the instance that owns that information and
will not be synced by any automated process. Self-service usage for HCM is not impacted. For the
Subscriber Only model, users (administrative or self-service) can enter updates in whichever system makes
sense or is required by institutional business processes, and the updates will be messaged to other system.
For the Owner/Subscriber approach, all updates for core bio-demo data (see list of synced data elements)
will be made in CS. Employees will not be able to use HCM Self-service to update core bio-demo data as it
is not synchronized back to CS. However, employees can use either CS Self-service for bio-demo data
updates or, for that matter, they could use the HCM Self-service that exists in the CS instance. As long as
the employee is updating a bio-demo data component in the CS instance, that update will be synced to the
HCM instance. In the HECH, core bio-demo data is maintained in the appropriate application (HCM or CS),
synced to the hub and then distributed, based on your governance rules.
42. What documentation will be provided?
A: A new Section in Campus Solutions PeopleBooks will be created. Updates will be made to the HCM
PeopleBooks, focused on Higher Education customers. We plan to also create additional Integration Guides
to explain how to deploy the services, External S/M and the other utilities that will support the integration.
43. Will there be pre-requisites for the CS HCM integration?
A: The customer must have created separate instances for CS 9.0 and either HCM 9.0 or 9.1. The
customer must have applied the HCM and CS bundles delivered in October 2010. See Knowledge [ID
1159773.1] in My Oracle Support for the correct sequence of applying HCM and CS Bundles (October 2010).
44. What is the impact of the separate instance integration on managing HCM and CS
maintenance?
A: Customers will need to apply core HRMS maintenance to the CS instance. If customers choose to use
North American Payroll in the CS instance to process Student refunds, they will need to also apply Payroll
maintenance to the CS instance. Oracle suggests that customers need to retest the delivered integration
only if we issue a data model change or a change in the integration itself (the publish or subscription pieces
of the messages). Other sorts of functionality changes around bio-demo data are not likely to require retesting of the integration.
45. Will supported versions of PeopleTools be consistent for CS 9.0 and HCM 9.1 (and
beyond)?
A: Yes, PeopleTools is backward compatible.
46. If a CSHR9.0 customer upgrades to HCM 9.1, what are the options for refunding
students?
A: Oracles recommendation is to use PSFT A/P for refunding functionality. We plan to deliver
enhancements in a future Feature Pack to support direct deposit capabilities for PSFT A/P. There will be no
provided integration between CS 9.0 and a separate instance of HCM Payroll. If customers want to use
North American Payroll for refunding, they will need to do so using the Payroll application that is part of the
CS instance. Customers that want to continue to use Payroll for processing Student Refunds would need to
do the requisite payroll setup in the CS instance to process student refunds alone. All other non-student
related payroll would continue to be processed in the separate HCM/Payroll instance. If customers choose

HCM - CS Integration FAQ Nov 2, 2010

Page 8 of 13

to use the Payroll application within the CS instance, they will need to apply Payroll maintenance to that
instance.
47. HCM 9.0 support ends in Dec 2011, with Regs/Legs/Tax updates provided through Dec
2012. Extended Support for HCM 9.0 is available through Dec 2014. How will
customers get fixes for HR Core and Payroll (tax) objects for the CS 9.0 codeline once
Extended Support for HCM 9.0 expires in Dec 2014?
A: Just like any other HCM 9.0 customer, after Dec 2014, customers will go into Sustaining Support for
HCM 9.0, including Payroll. If there are fixes required for core Person objects required AFTER December
2014, Campus Solutions will provide those for the Campus Solutions codeline, to ensure the integration
continues to work. For customers concerned about North American Payroll support after Dec 2014, the
suggested path is to evaluate processing student refunds through the PSFT A/P solution.
48. Will the use of HCM Payroll in the CS instance for student be supported when HCM 9.0
support ends in 2014?
A: There are no plans to extend support beyond the standard Oracle Sustaining Support. For customers
concerned about North American Payroll support after Dec 2014, the suggested path is to evaluate
processing student refunds through the PSFT A/P solution.
49. What changes to the GL interface and other Financial integration should we expect? Is
Oracle providing messaging to support moving all chartfields over to the HCM instance?
A: Student Financials will continue to send GL transactions directly to PSFT Financials as we do in the
existing HCM/CS 9.0 instance and the remaining GL transactions that get generated as a result of cutting a
check or processing a direct deposit will come from either Payroll (in the CS instance) or from the AP
instance to Financials.
PFST Financials publishes messages to which Student Financials subscribes in order to load Chartfields.
There is also the batch publish of accounting line information from Student Financials to PSFT Financials.
Regardless of the separate instances, any Financials related enhancements (e.g. support of additional
Project Cost Chartfields) or changes in Financials that has potential to impact the SF-GL interface would
need to worked upon by Campus Student Financials
Multiple nodes (CS and HCM instead of just a single HCM node) should not impact the integration.
Project Costing Chartfields: PS Financials supports the Project Costing chartfields but they are not
consumed/supported in the HCM/CS 9.0 instance today. (The underlying tables that store the chartfields
and the valid values are owned by HCM CS simply leverages those.) These additional chartfields are
supported in HCM 9.1. So, if a CS customer is project centric, meaning they do plan to use Project Costing
Chartfield functionality in HCM 9.1 and they decide to move to separate instances, then they would need
Project Costing Chartfield support in the CS 9.0 instance. We acknowledge that this is a valid
scenario/requirement that SF would need to support as part of the separate CS-HCM model but that
support is currently out of scope for FP4. We will evaluate the customer priority for this support for future
phases of the CS-HCM integration support.
50. What is the impact on FERPA controls with the separate instance? What about
restrictions around sharing Employee personal data?
A: There are no changes in the FERPA process. Students continue to use CS to indicate their FERPA
restrictions. Institutions would continue their (assumed) current business process in which CS is the
system of record for FERPA release/restrictions. The FERPA flag (defined as a Y/N value) is part of the PBS
message, so the value will be sent to HCM and can be stored in the existing Person_SA record. Technically,
FERPA does not cover Employee data. Employee data can be hidden/restricted in the CS instance using
delivered security.

HCM - CS Integration FAQ Nov 2, 2010

Page 9 of 13

51. In the Distinct Ownership model, how are faculty handled? Are faculty handled like
student-employees, who are in both databases but independently maintained?
A: Yes, the intent with Distinct Ownership is that the customer will maintain the core bio-demo data (e.g.,
name, email addresses) in BOTH HCM and CS. See the earlier comment on the continuum; customers can
choose to keep these two data elements in sync using delivered messaging, as a hybrid approach of
Distinct Ownership and the Owner/Subscriber model.

Section IV: Emplid Synchronization


52. How will Emplids be kept in sync between the separate instances?
A: All the configurations modeled retain the ability for the customer to maintain either the equivalent of a
single Emplid for HCM and CS or an actual single Emplid. The HECH uses a Universal ID to which other IDS
(e.g., EMPLID) is mapped; future enhancements include the ability to import an HCM-created EMPLID from
the HECH. In the Distinct Ownership approach, the customer will use External S/M to look at the other
instance before adding the new record, to see if the person (either student or employee) exists in that
instance. If the match is found, the new External S/M can import the persons Emplid as well as core biodemo data and the business process can continue. In the Subscriber Only model, the EMPLID defined in
the system of Person creation is published to the other system. In the Owner/Subscriber approach, all
persons are added to the CS instance, so all Emplids are assigned using that Installation counter.
53. Does Oracle recommend institutions maintain two ranges (sets) of Emplids? For
example, an institution may have a large (batch) student application/admissions SQR
that will now have to look at two instance/systems to determine if the person already
exists with an emplid.
A: Yes, for customers who are choosing to deploy the Distinct Ownership and Subscription Only models of
direct integration, the recommendation is to maintain two distinct ranges of Emplids in the CS and HCM
instances. For the Owner/Subscriber approach, all Emplids are assigned using the CS Installation Counter.
For the HECH bi-directional integration approach, the hub provides the ID synchronization capabilities, so
the Installation counters dont need to be modified. (Note: In the future, an enhancement to the HECH
Connector may include the ability to import an HCM-created EMPLID from the HECH; in that scenario, you
would want to maintain two distinct EMPLID ranges in HCM and CS to prevent data collisions.)
The CS batch loads will continue to execute S/M, as they always have. Search/Match will search against
the CS instance. Therefore, if you are using Distinct Ownership model, you will not be searching against
the HCM instance (only the CS instance). Currently, External Search/Match is not deployed against BATCH
jobs, only the online transactions. If you are using the Subscriber Only or Owner/Subscriber model, all
persons exist in the CS instance, so S/M will look at the full HCM/CS population by searching against CS.
We are evaluating the need to leverage External S/M with batch jobs against an HCM instance.

Section V: Portal and Security Configuration


54. Our school also has a portal database and we message over user profiles from CS/HCM
to our portal database as they are created. Are there plans to integrate userprofile
creation from CS 9.0 and HCM9.1 separately to the portal database?
A: Yes, this will be standard in the PS Enterprise Portal.
55. Whichever model, owner/subscriber or distinct ownership, is chosen, does the
PSOPRDEFN table need to be identical in both databases?
A: Not necessarily. For example, in a Distinct Ownership model, you might not want operators in your HCM
system to have entries in your CS system, only those users who NEED access to both systems (for example,
student-employees) a pure EMPLOYEE would have no need nor any real business having an operator ID
in CS.

HCM - CS Integration FAQ Nov 2, 2010

Page 10 of 13

56. Will security tables (PSOPRDEFN, etc.) be included in sync?


A: Yes, user profiles will be synced through standard process.
57. Where do User Profiles for portal aggregation exist? Is there a message to keep User
Profiles in sync between the two separate instances?
A: See Enterprise PeopleTools 8.50 PeopleBook: Security Administration > Working with User Profiles Across Multiple
PeopleSoft Databases.
58. It makes sense that in the Ownership/Subscriber model, with Campus Solutions as the
owner, messaging would go from Campus Solutions to the Portal to provision
psoprdefn in the Portal. This is because in the ownership / subscriber model, all
persons (students, faculty, and staff) will be present in Campus Solutions, as they are
now in the present combined database.
Related to the distinct ownership model: Will messaging to the Portal be from both
Campus Solutions and HCM? If so, aren't there possible collisions in the Portal? It
seems this could occur when a student is first created in Campus Solutions and later
hired as an employee in HCM and therefore is already in the Portal at the time of the
hire.
A: Both CS and HCM will message to the Enterprise Portal. User Profile attributes (including User ID, Roles,
and ID Type values) which exist in both CS and HCM databases will be reconciled in the Enterprise Portal at
subscription time. These also can be synced between CS and HCM as required. There is a good
description of how User Profiles are managed between multiple PeopleSoft databases in PeopleBook doc.
See Enterprise PeopleTools 8.50 PeopleBook: Security Administration > Working with User Profiles Across
Multiple PeopleSoft Databases.
59. Can you register a CREF from an independent database in an application portal of
another database?
A: Yes, you can add a link to a page which resides in another database instance to the application portal
navigation that is resident in the original database. In other words, you can add a CREF for a CS page in
the HCM 9.1 application portal navigation. In fact, this is one of the options to streamline navigation for
users deploying the Owner/Subscriber model.
60. The value HRMS is delivered by default as the Portal NODE during the PeopleSoft
Enterprise Portal installation. How do we create a separate node for CS (Campus
Solution) and make sure the CREF is referencing this node?
A: In order to register an external content reference, you need to point that content reference to the
external source. This is accomplished by defining the new node in the external application and then, when
registering the content references in your hosting portal, including the external node instead of the internal
node. This can be done both in the Enterprise Portal as well as the standard Application (PIA) portal. For
example, in an Owner/Subscriber model in which Campus Solutions is the system of record, you could
easily include links in your HRMS application portal to components in your Campus Solutions instance by
defining the menu and component in your Portal CREF definitions list, but rather than pointing to the local
(HRMS) node, you would point to the external (e.g., CAMPUS) node.
In addition to simply registering external content references in your portal navigation, Peopletools
8.5 allows for the use of Related Content, the ability to embed components directly within another
component to allow for a more seamless business process that spans multiple components or transactions.
As with the aggregated navigation, you will need to create an external node and references that external
node when registering your related content.
For more information on defining and configuring external content references, please see the Portal
Navigation Aggregation Guide. For more information about Related Content, and registering CREFs in
portal structures in general, please see the PeopleSoft Portal Solutions Peoplebook.

HCM - CS Integration FAQ Nov 2, 2010

Page 11 of 13

61. Will Oracle provide an automatic way for customers to lock down tables for editing - for
example, if the table setup is sent from HCM to CS, will the subscriber environment be
open for editing? If not, how will customer prevent their two instances from getting
out of sync.
A: We are not delivering anything to PREVENT updates of shared tables in HCM and CS. We expect
customers will enforce controls on data entry via policy and/or changing Security Permissions. We are
considering whether we will deliver support for this type of control in the Owner/Subscriber approach in a
future update (for example: pages that should be Display only.)
62. In the Distinct Ownership model, for administrative staff using Campus Solutions for
administrative functions, what is needed to provision them in Campus Solutions? Are
they handled like faculty in the Distinct Ownership model?
A: In order to access pages/components, etc., the user (admin staff) will need to have an operator record
in the CS instance (OPRID). However, they do NOT have to have an EMPLID there are different ID
TYPES that can be associated with an OPRID (including NONE, as well as Employee, etc.). Permissions and
Roles are not tied to ID TYPES. Please consult Peoplesoft Security Peoplebooks for more details.

Section VI: Reporting


63. What impact on the existing SQR, Crystal reports and Queries should an institution
expect once the instance is split? What about existing views, etc.?
A: The first step is to understand what data is kept in sync, in each database. Then, understand the
source of the data for each report or Query. You may either need to create custom integration to support
the data needs of that report or look at creating new sources for that report.
Note that you cant use PS Query to access records across two databases.
Data Model changes are not taking place by virtue of this project. Customers who use the Campus
Solutions and/or HCM Warehouses will continue to utilize those reporting structures.
The PS Campus Solutions Warehouse does pull data from different sources and in some cases it does
aggregate data (but that is not the case today for PERSON related data). The impact the separate instances
has on the warehouse is similar to the impact on the reporting side. The warehouse needs to identify
where to pull the master data from; probably the most complicated scenario is the distinct ownership,
where the data may need to be pulled from different databases. For customers that will create their custom
reports, they should be aware of the implications. If they just do counts out of context, then they could
have issues. In context reports should behave as expected. The Source SYS ID key field will be the
differentiator.

The EPM Warehouses rely on a Source System ID to join dimensions to the FACTs and to do
lookups. If you are using a Campus Solutions FACT, it will look to do the join using a dimension
even if commonthat has a row with the same source system ID (it doesnt really care what it is,
as long as there is a match).
In cases where the Personal data is duplicated across the CS or HCM DB, it will work, but there will
be two data rows for the same person in the Dimensions. Not a technical issue, though customers
may question why there are two rows of data for a single person. With the current design, there is
no easy way to alter this result and we deem it too invasive at this point to change the functionality.
In the case where Personal data only exists where it is neededDistinct Ownershipit should also
not be a problem. Employees who are not students will only be needed for HCM FACTS and
Students who are not in HCM will only be used in CS. Where data is duplicatedStudents who are
also Employeesthe same thing will occur with duplicated rows (but for the source sys ID) and it
should work fine as well. The joins will take place taking into account the source sys ID. It is the
customers responsibility to ensure that they synch up where necessary for those who need to be in
both DBs.

HCM - CS Integration FAQ Nov 2, 2010

Page 12 of 13

Subsequent to the Phase 1 updates, Oracle may attempt to analyze the impact each of the three most
typical integration approaches (owner/subscriber, distinct ownership or Integration with Constituent Hub)
could have on reporting. We will ask our Focus Group for support in this analysis.

Section VII: Miscellaneous Topics


***Our intent is to continue to update this Document with additional Questions and Answers as
our customers leverage the integration capabilities. Customers should leverage the normal Support
process to record their question or issue and if that question is applicable to the majority of
customers, well add it to this document.

HCM - CS Integration FAQ Nov 2, 2010

Page 13 of 13