eForms Framework Screenshots Session #10732 March 24, 2005 HEUG 2005 Conference Las Vegas, Nevada

The presentation shown in our session includes a live demo of the eForms system. This presentation consists of screenshots of eForms, similar to the live demo. What We Will Cover

Each business process is a Form Type Form Types use Approval Rule Sets Form Tasks describe the purpose of individual steps in Approval Rule Sets Task Steps are the pages used to perform the task Form Actions describe what action the user performed to complete the task eForms Concepts

Each business process, with its various conditional branches, is a Form Type. A Form Type could also replace a specific paper form.

A Form Type may or may not use approval processing, store form tracking information, and perform employee-specific operations. The main data record is where the actual form fields will be stored.

Form Types that are destined for entry into a delivered system component, like Job Data, do so through an asynchronous message. This lets control return to the user immediately, and allows traffic into the system to be managed independent of entry.

An Approval Rule Set is a chain of participants a form can be routed through. Approval Rule Sets are defined in Application Designer. Some of the steps may be skipped conditionally, as we’ll discuss later. Each of the steps has at least one Role associated with it, whose members will receive s and/or worklist entries for this Form Type. Approval Rule Sets can be used by multiple Form Types.

The default Approval Rule Set is the chain of participants this form will typically be routed through. We’ll see later that this can be conditionally overridden, so a Form Type can use multiple Approval Rule Sets.

On the Form Rule Tasks page, we associate a Task with each approval step of each Approval Rule Set we will use for this Form Type. Let’s find our default Approval Rule Set, Y_STUDENT.

Here we specify what Task is to be performed by each user in our business process. The Departmental HR User will Add a new form; the Departmental Approver, Front and Back Office users will Evaluate the form.

The Task we assign to each approval step determines what pages the user will see when form comes to them. For example, the International Office shouldn’t see the employee’s comp rate, so they need a different page than the Back Office sees.

Tasks are defined on the Task Table. Some tasks are standard, and will be used on most forms, like Add, Update, Evaluate and View. Custom tasks can be defined for use when a standard task doesn’t apply.

The Form Task Navigation page is where the rubber meets the road. Here we specify what pages the users will actually see as they perform tasks to manage this form. Let’s look at the Evaluate task.

Here we can set the Task and Step Titles, which will appear at the top of the user pages as they move through the steps. The pages also display ‘Step X of Y’ at the top – the Count? checkbox determines whether the step counts in the Count!

The Step Instructions also appear at the top of eForms pages. By making this editable from a setup table, simple text changes don’t require code changes!

Here is where we define what page this step of this task of this Form Type actually displays!

This also provides a target for hyperlinks that will be used throughout eForms. An for this form with a link to Evaluate the form will generate its link from this setup information. With eForms, navigation is completely setup table-based!

Let’s look at how that setup information translates to what the user sees.

This is a Departmental Approver’s worklist. He has a worklist item to evaluate a Hire form for Jane Doe, who is being hired as a student. Here’s a flashback…

We’re right HERE in our business process.

That means our task is to Evaluate the form.

These are the user steps needed to Evaluate a Hire form. End flashback…

… and let’s perform the task!

At the top is our Task Title of ‘Evaluate Hire,’ followed by our Step Count, Title and Instructions. All of these elements can be changed on the setup pages.

Most importantly, we never had to code the link to this page… it was automatically generated from our setup data!

Here is our second and last step in the Task. We have completed our part of the business process, and this form is off to the Student Front Office! (The International Office was conditionally skipped, because Jane is a citizen.)

Speaking of which, let’s look back at the Eval Intl task steps. Remember we used a different task because they needed to see a different page.

Here is the navigation for their custom Evaluate page.

Let’s pretend we’re an International Office user and look at our worklist.

We’ll choose a Hire form to review.

Here is the first step of the Eval Intl task. The page is appropriate for the distinct task the International Office needs to perform.

Adding a step to the task is as simple as inserting a row…

…and adding the appropriate information. Business analysts can add and remove pages (providing they are already developed) without code changes.

As we mentioned, Custom Tasks allow you to display different pages for distinct activities in the system. They also are used for custom routings, like conditionally skipped or repeated tasks. Custom Tasks

One of the most valuable feature sets of the eForms framework is management. Complex systems that would be unbearably tedious with standard PeopleSoft workflow become manageable, with little or no developer time needed.

s are triggered by Form Actions. An Action is what the user did to complete the Task. For example, when Evaluating a form, the user might complete the task by approving the form, denying it, or recycling it.

Any Action taken on a form may call for one or more s to be sent. For example…

…when a form is approved, we want to send an to the next approver, plus an FYI to the originator. By entering the template names here, the s will automatically be generated when the form action occurs.

The templates are HTML objects, which are maintained in App Designer. A business analyst can manage them if given access to create and modify these objects. Standard bind variables allow form info, employee info and links to be passed in.

The preceding template generates s like this. Note the hyperlinks. These are also setup table-driven. The first, ‘Link to Evaluate Hire,’ takes the user, through authentication, directly to the first step of the Evaluate task.

Here is the setup table for hyperlinks. We will choose the General Evaluate template.

Each line on this page generates a link in the named template. We can either specify a Form URL or a URL Definition. The Form URL feature is exceptionally powerful.

The values here are the valid Form Tasks. Just by choosing one, we will generate a link in this template that will take the user to the first step of that task for the form the concerns. Again, this is done without any coding!

We have one more feature to review that, combined with what we have already covered, gives eForms the power and flexibility to handle extremely complex business processes. The feature is Form Conditions.

This is the setup table where Form Conditions are defined. They describe states a form may be in that require special handling. After defining a Condition here, they are associated with the Form Types to which they apply.

Here several Conditions have been associated with the Form Type.

Form Conditions allow for branches in the business process For each Form Condition of a Form Type, you can override the default: Approval Rule Set Notification Template associated with each Form Action Task Steps Form Conditions

Let’s look at the condition PTNSHRLY. BYU’s Part-Time, Non-Student Hourly hires are processed by a different hiring office than the Student Hires we’ve been looking at. They therefore use a different Approval Rule Set: Y_STAFF.

To use the routings and the tasks for the different approval set, the condition PTNSHRLY overrides the Approval Rule Set. When this condition is set, Y_STAFF will be the approval rule set that will govern where the form goes.

Now STHRCONC. When a student adds a second job on campus, their first job needs to approve the hire. We’ll need a different Approval Rule Set that includes them, but we also need…

…different s. The standard Evaluate template isn’t enough, because we’ll need to give more specific instructions. So we override the templates that are used when this form condition is set.

One more: STUCNTRCT. Student Contract employees use the same Approval Rule Set and templates as Student Hourlies, but their compensation pages have to be different to gather contract pay information.

We need to override the Task Steps to point to different pages – Contract pages. We’ll look at the Evaluate task again.

It looks the same as the default Task Steps for Evaluate, except…

…the Page Name is different! When this condition is set, the users that perform the Evaluate task will see a contract-specific page. That leaves one last question: How do these various conditions get set?

When a form is being worked by users, Form Conditions are changed programmatically based on the data, the environment, the user, etc. When the Form Condition changes, the system automatically finds the user’s place in the new Approval Rule Set and stack of Task Steps. Form Conditions

Let’s see how this works. Here we are in the Add task of the Hire form. On this page we have set the Employee Class to Student Hourly. When we hit Next…

…we actually run CODE! Yes, we do use some code in eForms. One of the primary goals of the eForms framework is to limit coding in forms design to the few places where a conditional test must be applied in order to decide what to do next.

The code only needs to decide what Condition the form is in, and set that Condition. Everything else – the workflow participants, the pages that are seen, the s that are sent, the hyperlinks that appear in those s – should happen automatically.

I like to call these condensed chunks of code SmartSpots. In this one, under the Next button, we test what the user entered in the Employee Class field. When the chose Student Hourly, we set one of two Conditions: say, STUHRLY.

The eForms framework takes it from there. The STUHRLY Condition has no overrides, so we go to the default Step Three for the Add Task for the Hire Form Type. Now, let’s go back and use a different Employee Class.

This time we’ll choose Student Contract, which you will recall needs a special compensation page.

Our SmartSpot detects the conditional branch in our business process, and the marvelous SetCondition() function loads up the STUCTRCT Condition with its navigation overrides, and…

…here is our Contract Compensation page! We only need enough code to figure out what the Condition is, and the eForms framework takes care of the rest.

Thankfully, many business processes are less complex than BYU’s Hire process. Whether the process has no conditional branches or many, eForms allows the process to be represented in setup table-based definitions, rather than procedural code. For a discussion of the benefits this approach brings to the enterprise, please refer to the main presentation for this session. Feel free to contact us if you’d like a truly live demo, or with any questions you may have. Thanks! Summary

Paul Taylor Technical Consultant PeopleSoft HCM Upgrade Project Gideon Taylor Consulting LLC for Brigham Young University Alisha Steere Assistant Product Manager PeopleSoft HCM Upgrade Project Brigham Young University Contacts

This presentation and all HEUG 2005 presentations are available for download from HEUG Online