Creating an Automated Check-In Application

Automation is a key feature of Process Director. While most automation focuses on managing the steps of a single process—determining who approves what, and when—Process Director also supports automating the invocation of processes themselves. This topic demonstrates that capability by building a sample automated check-in application using Goals and Knowledge Views.

Before Goals existed, process invocation required a Windows Scheduler trigger calling a Knowledge View via the bputil.exe utility. While functional, this approach was unwieldy, because it required configuration outside of Process Director, had no queryable history, and left processes hanging in memory if called incorrectly. Goals address all of these limitations by providing built-in scheduling, a queryable result history, and direct integration with the rest of the Process Director object model.

Overview

The sample application tracks book checkouts and automatically prompts users to return overdue items. The core design principle is that the checkout process should end immediately after the user is notified—no long wait tasks. A year later, the goal handles all follow-up automatically. This example uses books as the check-out/check-in objects, but it can be used for documents, equipment, or any other type of inventory control process where items need to be periodically returned, exchanged for maintenance reasons, or other types of check-out/check-in processes.

Application Architecture

This example application consists of two logical parts: A Book Checkout process (the starting point) and an Automated Check-In process (the goal-driven follow-up). Together, they require the following objects:

• Book Checkout Form
• Checkout Timeline
• Checkout Notification email template
• Check-In Notification email template
• Notify Book Due Timeline
• Prompt Book Check-In Knowledge View
• Books Due Knowledge View
• Due Date Check Business Value
• Books Due Goal

Build these objects in the order listed above. Each object depends on the existence of the ones before it. In particular, the email template must exist before the timeline that references it, and both Knowledge Views must exist before the Business Value and Goal can be configured.

Why Not Use a Long Wait Task?

A common first instinct is to add a year-long wait task to the checkout timeline. This approach works, but it creates a persistent, in-flight timeline instance for every checked-out item. Process Director's timer process must evaluate every running timeline instance on each timer run. With many checkouts, this overhead grows substantially—timer runs that previously took a few minutes can grow to thirty minutes or more as idle timelines accumulate.

Before using a long wait task, consider whether the process truly needs to be unbroken from start to finish. If a later step must reference an earlier activity's data within the same process package, a wait task is appropriate. If, however, the follow-up process can operate independently using data already stored on the form, it is far more efficient to end the original process and invoke a new one via a goal when the time comes.

Equipment checkouts, book loans, and recurring maintenance schedules are all good candidates for this pattern: The checkout data is stored on the form, the due date can be derived from that data, and there is no need to keep a process timeline running while waiting.

Part 1: Book Checkout Process

Book Checkout Form

The form requires only three data fields and two tracking fields.

Data fields:

• Book Title: The name of the item being checked out.
• Checkout Date: Used to calculate when the item is due.
• Checked Out By: A User Picker field identifying the person who checked out the book. This field drives task assignment in the check-in process.

Tracking fields (checkboxes):

• Checked Out: Indicates the item is currently on loan. Set its default value to checked so that newly submitted forms are automatically treated as active checkouts. In production, you may choose to hide this field from users, since it is a status tracking field rather than a data entry field.
• Check-In Prompted: Indicates that the check-in process has already been started for this checkout. This field prevents the goal from spawning a duplicate check-in process on subsequent evaluations. Like Checked Out, this field may be hidden in production environments.

For the Checked Out By field, setting the default value to Form Submit User is convenient in a demo environment but is typically not appropriate in production, where an administrator or librarian—not the person submitting the form—would select the borrower.

Deriving the due date: There are two ways to handle the due date. The approach used in this application derives it programmatically at the time it is needed, using a system variable on the checkout date field with days=365. This avoids storing a redundant field but makes the Knowledge View filter logic less intuitive.

An alternative approach is to add a Due Date field to the form. Make Checkout Date an event field, and configure it to update Due Date by adding 365 days whenever the checkout date changes. With a stored due date, the Knowledge View filter becomes a straightforward comparison: Due Date is less than or equal to current date. This is generally clearer and is the recommended approach for production implementations.

Checkout Timeline

The checkout timeline sends a single notification and ends immediately. It should have a definite end—no wait tasks. The notification informs the user which book they checked out, when they checked it out, and when it is due.

Because the timeline ends immediately, there are no in-flight process instances accumulating over the loan period. All follow-up is handled by the goal when the due date arrives.

Part 2: Automated Check-In Process

Check-In Notification Email Template

Create this template first, before building the Notify Book Due Timeline, so that it is available as a reference target when configuring the timeline's default email template. The notification should include the book title, checkout date, and a link using the Email URL system variable so the recipient can open the form directly and complete the check-in task.

Notify Book Due Timeline

This timeline governs the check-in process for a single overdue book. It is invoked by the Prompt Book Check-In Knowledge View, which passes in the original checkout form instance.

Leave the Form for Timeline property blank. When the Knowledge View invokes this timeline, it automatically attaches the checkout form instance from the Knowledge View row. Setting Form for Timeline would cause a new, empty form instance to be created instead—which is not what you want here.

Set Default Email Template to the Check-In Notification template.

The timeline requires three activities, in order:

1. Set Orig Form to Default: A Form Actions activity. Configure it as follows:

   • Form Definition: Book Checkout Form
   • Set this as the default form instance for the timeline: Checked
   • Add New Form Instance: Only if the form does not already exist in the package

   When the Knowledge View kicks off this timeline, the original checkout form is already attached to the package. This activity designates it as the default form and ensures no duplicate form instance is created.

2. Set Checkout Prompted: A Custom Task activity using SetFormData. Set the container form to the Book Checkout Form and set the Check-In Prompted field to 1. This marks the record so the goal will not start a second check-in process for the same checkout on the next evaluation.

3. Check Book In: A user activity assigned to the person identified in the Checked Out By form field. The task instructs the user to uncheck the Checked Out checkbox, which constitutes the check-in action. Use the Task Assignment via Form Field option to route the task to the correct user.

Prompt Book Check-In Knowledge View

This Knowledge View is the bridge between the goal and the per-book check-in processes. When the goal detects overdue books, it runs this Knowledge View, which in turn invokes one instance of the Notify Book Due Timeline per row returned.

Configure it on the following tabs:

Configure tab: Set Knowledge View Results to Run a Process, then click Update. This setting causes a new timeline instance to be invoked for each row returned by the Knowledge View. After saving, return to the Properties tab to set the newly exposed Select Process to Run on Each Object property to the Notify Book Due Timeline.

Once Knowledge View Results is set to Run a Process, running this Knowledge View manually—for example, by clicking Update and Run during development—will invoke live process instances. Do not run this Knowledge View interactively after this point unless you intend to start actual processes.

Properties tab: Set Forms Associated with Knowledge View to the Book Checkout Form.

Options tab: Uncheck all object type options except Form Instances. If Workflow Instances or Timeline Instances are also checked, the Knowledge View will return those objects as rows too, and will attempt to invoke a separate check-in process for each—resulting in duplicate process invocations.

Columns tab: No configuration required. Since this Knowledge View is never displayed to users, the columns returned do not matter.

Filter tab: Apply all three of the following filters using AND logic:

• Checked Out equals 1 (checked)
• Checkout Date is less than or equal to 365 days ago
• Check-In Prompted is not checked

The third filter is critical. Without it, every goal evaluation would start a new check-in process for every overdue book, even books that already have an active check-in task assigned.

The Days Ago filter value does not compare a count of elapsed days—it calculates and returns a date value (the date that was 365 days before today), then compares that date against the Checkout Date field value. If you find this logic difficult to reason about, consider storing an explicit Due Date field on the form and filtering on Due Date is less than or equal to current date instead.

Books Due Knowledge View

This is a separate, reporting-friendly Knowledge View that returns overdue books. Its purpose is to provide the data source for the Due Date Check Business Value. It uses nearly the same filter logic as the Prompt Book Check-In Knowledge View, with one difference: The Check-In Prompted filter is omitted. This Knowledge View should return all overdue books regardless of whether the check-in has been prompted, so that the Business Value and Goal accurately reflect the current state of the library.

Configure it as follows:

Properties tab: Set Forms Associated with Knowledge View to the Book Checkout Form.

Configure tab: Leave Knowledge View Results set to Displayed in Grid (the default). This is a normal, viewable Knowledge View.

Options tab: Check Form Instances only.

Columns tab: Return at minimum the Name column. Add the checkout date and any other fields useful for reporting.

Filter tab: Apply the following filters using AND logic:

• Checked Out equals 1 (checked)
• Checkout Date is less than or equal to 365 days ago

You will likely need a reporting view of overdue books regardless of whether you build this automated application. By building this Knowledge View now, you satisfy both reporting and automation needs with a single object.

Due Date Check Business Value

This Business Value returns the count of rows from the Books Due Knowledge View. The goal uses this count to decide whether to invoke the check-in process.

Set the data source to Knowledge View Data Source and select the Books Due Knowledge View. Set the property type to Number of Knowledge View Rows and name the property Books.

You must also set the Execute Knowledge View Under This User Context property to a user with permission to run the Books Due Knowledge View. Business Values are evaluated in a system-wide context and cannot inherit the current user's permissions. If this property is not set, the Business Value will work correctly for administrators (who typically have access to everything) but will fail silently for ordinary users.

Consider creating a dedicated service account—for example, a "Knowledge View User"—and assigning it to a group with view and run permissions across the relevant areas of the Content List. Reference this account in all Business Values that use a Knowledge View data source.

Books Due Goal

The goal ties everything together. It evaluates the Due Date Check Business Value and takes action based on the result.

Execution Options: Set Execute Actions When to Conditions Are Met. Set the Execute Knowledge View Under This User Context property to the same user account used in the Business Value. This is required because the goal's Run Knowledge View action must execute in the context of a user with appropriate permissions.

On a development system where the configuring user has full permissions, omitting the user context on the goal may appear to work correctly. On a production system, goal actions will fail for users who lack permissions to run the referenced Knowledge View. Always set this property explicitly.

Conditions and Results: Configure two mutually exclusive conditions:

Condition 1: Books Due:

• Condition: Due Date Check.Books > 0
• Result: Books Due
• Action: Run Knowledge View
• Knowledge View: Prompt Book Check-In

Condition 2: Nothing Due:

• Condition: Due Date Check.Books = 0
• Result: Nothing Due
• Action: Set Result Only

The goal uses Run Knowledge View rather than Run Process because the goal itself does not know which specific books are overdue—it only knows that overdue books exist. The Prompt Book Check-In Knowledge View retrieves those books and starts one process per row. If five books are overdue, the Knowledge View starts five timeline instances.

Evaluation Frequency: Set the schedule to match your operational requirements. For equipment with regular maintenance deadlines, a daily evaluation is typical. For this demonstration, the goal is left inactive and evaluated manually using the Evaluate Now button.

Testing the Application

To verify the application end-to-end, create at least one form instance with a checkout date more than 365 days in the past (with Checked Out checked) and one with a recent checkout date.

1. Open the Books Due Goal and click Evaluate Now. The goal result should change to Books Due, and a check-in task should be assigned to the user who checked out the overdue book.
2. Complete the check-in task by unchecking the Checked Out field on the form, then click Evaluate Now again. The goal result should return to Nothing Due.
3. Verify that no duplicate tasks were created for books that had already been prompted. Because the Prompt Book Check-In Knowledge View filters on Check-In Prompted, a second goal evaluation should not start a new timeline for a book that already has an active check-in task.