How to structure the unavoidable: Customizing PeopleSoft to support business needs.

Every business has its own explicit and implicit standards about how to modify Commercial off-the-Shelf (COTS) software to integrate with the business operations and the application landscape. Sometimes there are strict architecture principles, sometimes experience has learned not to go too far in customizing.Oracle has provided several ways to integrate PeopleSoft with other applications. Integrations between different PeopleSoft products (e.g. HCM and FSCM) only have to be configured and recently integrations for the co-existence with Fusion Applications were delivered. Oracle is also moving forward to use Fusion Middleware to extend PeopleSoft capabilities far beyond PeopleTools.

But what kind of customizations are we talking about? I have defined 3 types of customizations based on recent projects and PeopleTools capabilities.


1.     Augmenting PeopleSoft

While PeopleSoft facilitates in most of the fields you might need in a business process, every now and then there is that one piece of information you need to store on a page that just does not fit.


These changes most of the time are small, but very useful. You could do this in 3 different ways

  • When this data element is only used in PeopleSoft and alterative fields are available in the records on the page, customizations can be minimized by using a suitable alternative field. Sometimes you have to place or move the field on te page and change te label, but the impact is minimal.
  • A whole different approach can be used when the data element is used in multiple applications and PeopleSoft doesn’t need to be the owner of the data. By storing the data elsewhere in the application landscape and showing it in PeopleSoft using related content  all data is still on te same PeopleSoft page. No customizations in PeopleSoft are needed, since related content is just setup. Keep in mind that a (foreign) key structure is needed to relate the PeopleSoft data to the external data.
  • Sometimes data elements cannot be stored in an alternative field, or PeopleCode is needed to enforce business logic. In this case adding your own fields with PeopleCode is the easiest way to go. You could work with sibling records and copies of vanilla screens to minimize impact on patching and upgrading.

Other custom objects of this type are queries, reports and dashboards. Although they are custom developed objects, most of the time they are not seen as customizations but as personalized views on PeopleSoft data, because they do not alter PeopleSoft logic or out of the box objects.

2.     Changing logic

The basic principle in a PeopleSoft implementation is changing business processes to align with the best practices in PeopleSoft and not the other way around. Nonetheless there can be processes essential for your business, industry or country that cannot be supported (fully) supported with available PeopleSoft functionality.

  • The first thing to do is check Oracle support about the missing functionality. You can file an enhancement request. When regulation or legislation is involved Oracle will likely provide this functionality.
  • When the required logic is specific for you business, Oracle most of the time will not provide this. You can develop this logic in Application Designer either as a permanent or temporary solution. When doing this, make sure you have clear development guidelines.

Keep in mind you can re-design nearly the complete logic of PeopleSoft using Application Designer, but you will lose Oracle Support and won’t be able to patch or upgrade.

3.     Integrating systems

When a mix of applications is required to fully support your business needs, PeopleSoft can be integrated with other systems. Oracle provides several standard integrations to specific products or services using the integration broker and SOAP messaging. Of course not all possible integrations can be predefined.


You can create your own integrations basically on 3 levels.

  • The lowest level is integration on a database level by providing access to the database for other applications. This type of integration is used for large volume and/or real time data flows, like integrations PeopleSoft data to BI universes. All PeopleSoft logic is ignored in this way of integration, so be very careful to explain how the PeopleSoft data model must be interpreted. Especially when you provide access to alter data (a scenario I would try to avoid), make sure data integrity is kept, since this is done in PeopleSoft on the logic level and not the database.
  • In the logical layer it is possible to use batch processing or queries to exchange data with other applications. In this case Application Engines and PeopleSoft Query can be used. You can apply custom formatting and logic to make it easier for other systems to interpret the data.
  • Finally you can use the integration broker and component interfaces for real time data exchange using XML messaging. This way PeopleSoft provides integration points for external systems with all application logic incorporated. In a service oriented environment this is the preferred way to link your data and applications to provide integrated functionality.



It’s amazing what you can do with PeopleSoft and there are many creative ways to use PeopleSoft in a tuned solution for your business. Just keep in mind not all solutions leverage the benefits of PeopleSoft as well as possible. And certain solutions will block your upgrade strategy and void your right on Oracle support.