Phire 15.

1
Application Configuration
Copyright © 2020, Phire. All rights reserved.
The Programs (which include both the software and documentation) contain proprietary information; they
are provided under a license agreement containing restrictions on use and disclosure and are also protected
by copyright, patent, and other intellectual and industrial property laws. Reverse engineering, disassembly,
or decompilation of the Programs, except to the extent required to obtain interoperability with other
independently created software or as specified by law, is prohibited. The information contained in this
document is subject to change without notice. If you find any problems in the documentation, please report
them to us in writing. This document is not warranted to be error-free. Unless permitted in your license
agreement for these Programs, no part of these Programs may be reproduced or transmitted in any form
or by any means, electronic or mechanical, for any purpose.

Change Request Workflow

The workflow feature in Phire provides the ability to identify the required tasks that guide a
Change Request (CR) from inception through resolution. Each CR Type has a workflow
associated that dictates how a CR proceeds from start to finish. The workflow for a CR is set
when the user creates a new CR and selects a CR type. CR types are user-defined to allow as
many different configurations as necessary.

Each task in the workflow can be configured to meet your business requirements. Some of the
attributes of the workflow task that can be configured include task description, type of task, status
codes, default assignee, and e-mail notifications. A set of pre-defined workflows are supplied
with Phire to serve as a starting point for building out the workflow that represents your change
management processes.

The workflow configuration at the time a Change Request is created serves as the template of the
workflow that will be followed for that CR. Changes made to the workflow configuration after
the CR has been created will not affect the processing of that CR.

Here is a sample of the CR Task page showing a typical workflow:

Copyright @ 2020 Phire Inc. All rights reserved. Page 1 of 20

Workflow Tasks
An open CR has a single task in the workflow that is “current” and will be shown on the CR Task
page with the icon. Tasks can be completed in different ways depending on how they are
defined in the workflow. A completed task is shown with the icon.

The simplest type of task is a manual task, which is completed by clicking a button on the CR
Task page. Completing a manual task will usually advance the workflow to the next incomplete
task; however, the workflow configuration can be configured to have multiple targets if
necessary. If more than one target is configured, then a prompt is presented when a manual task
is completed so that the CR can be routed to the appropriate task.

Another type of task is an “automatic” task, which is marked complete automatically when a user
performs an operation in Phire such as adding objects to the CR, creating a version set backup, or
entering a resolution. When an automatic task is completed, the current task advances to the next
incomplete task in the workflow. In most cases, holding the mouse over one of the buttons on
the page will reveal some quick information about how the task operates. In cases where the
button is disabled, this text often describes why the button is inaccessible.

The Task Information button is also available to show details regarding how the task is
configured to operate and what each of the available action buttons will do:

Copyright @ 2020 Phire Inc. All rights reserved. Page 2 of 20

A task can also be configured to allow it to be “failed”. If defined as able to be failed, an additional
fail button will appear on the task when the task becomes the current task. A previously failed
task will be shown with the icon. The workflow configuration can accommodate one or more
target tasks when a task is failed. If more than one is configured, then a prompt will offer the
user a choice of where to fail back in the workflow. If only one target has been configured, then
there is no prompt and the current task is immediately routed to that target step defined in the
configuration.

An example of a task that can be failed is the Testing task, in which a tester can advance the
workflow to the next task (such as final approval before the move to production) or fail the
workflow back to development for additional work. Depending on the configuration, the reason
for the failure may be required.

Once a task has been failed, the additional button is shown on the task, providing access to
view the history of failure reasons given:

Copyright @ 2020 Phire Inc. All rights reserved. Page 3 of 20

Tasks can also be configured as optional and can be “skipped”. In this case, an additional button
is shown allowing the task to be skipped and the workflow advancing to a predefined future task.
A skipped task will be shown with the icon. This feature is useful for tasks that are not always
required, allowing the users to record whether it was completed or not for a CR while advancing
through the workflow.

The workflow configuration accommodates one or more target tasks when skipping a task. If
more than one is configured, then a prompt will offer the user a choice of where to skip forward
to in the workflow. If only one target has been configured, then no prompt is shown, and the
current task is immediately reset based on that configuration. Depending on the configuration,
a reason may be required and captured in a form resembling the failure reason noted above.

Tasks can also be configured as “manual anytime,” allowing them to be completed even if they
are not the current task just by clicking the associated button. This feature is not available for
task types that cannot be completed out of sequence, such as migration tasks.

Workflow Configuration
There are two facilities that allow you to manipulate the workflow. First is the Administer
Workflow component (Phire > Administration > Administer Workflow), where you can review
and change the workflow for a CR type. The second is the Domain Setup Wizard (Phire >
Administration > Domain Setup Wizard) which provides a single point of access to the entire
domain configuration, including the code values, descriptions, and workflows that make it up.

For the purpose of this document, we will use the Domain Setup Wizard to describe the pages
related to the workflow and the various settings that are available.

Workflow Definitions
Here is a view of the main page in the Wizard for the workflow configuration:

Copyright @ 2020 Phire Inc. All rights reserved. Page 4 of 20

This page provides a view of the current settings for the workflow, including all the steps and
many of the details related to how they are configured. You can add and remove steps by using
the and buttons at the left.

Copy Workflow
The Copy Workflow button is available in the Domain Setup Wizard Workflow Definitions page.
It enables you to easily copy the workflow for the selected CR Type to another CR Type within
the same domain. The following prompt page is shown so that you can select the target Type for
the copy operation:

Select one of the available Types in the Copy to Type drop-down box and press OK to complete
the copy operation.

Renumber
This feature works with the “Increment” field on the page to make renumbering the steps quick

Copyright @ 2020 Phire Inc. All rights reserved. Page 5 of 20

and easy. Using this feature will renumber the steps using the same order in which they are
currently presented. All of the underlying “Advance to Step”, “Fail to Step”, and “Skip to Step”
references will be updated automatically to reflect the new step numbers. To reorder the steps,
use the Edit Details page described below.

Notifications
The e-mail notifications are configured for each task by clicking the icon. Whenever any of
the configurable events occurs for a CR task, an email is sent by the system. Any task that has
notifications configured will have this icon instead: . The format and contents of the email
and the addressees are all configured on the secondary page. The email notification
configuration is also available at the bottom of the Edit Details page described below. For
further detailed information on configuring the e-mail notifications, refer to the document
entitled Email_Notifications.pdf.

Edit Details
The detailed configuration information for each step is editable through this button on the page.

Starting from the step you opened, the Edit Details page also allows you to navigate through the
series of steps or jump to the start/end without needing to return to the main workflow page by
using these buttons: and . The following information describes the
options that are available for configuring individual tasks in the workflow.

Copyright @ 2020 Phire Inc. All rights reserved. Page 6 of 20

Step and Task Name
The Step value represents the step number that will be shown on the CR Task page and provides
the sequence that the tasks will be placed in. The numbers do not need to be sequential, and you
may wish to leave gaps for easier editing in the future (e.g., 10, 20, 30…).

You can reorder the steps from this page by simply changing the value; when you tab out of the
field, the page will immediately be reset to reflect the new order. Edits are also performed at that
time to verify the reasonableness of the “Advance to Step”, “Fail to Step” and “Skip to Step”
references that may exist for the task in question.

The available values for the Task Name value are defined in the Task Code Definitions page and
they are ultimately shown on the CR Task page as the task descriptions.

Task Trigger
The task trigger identifies how a task is to be “completed,” or what action takes place when a task
is marked Complete. For example, MANUAL tasks are marked completed and the workflow is
advanced by clicking the button on the CR Task page, whereas the PROJFILE trigger causes a
project of PeopleTools objects to be exported to a file when the button is clicked. Another example
is ADDOBJ, which is marked complete when an object is successfully added to the CR. Some
other characteristics of the task are derived based on the trigger selected, including whether a
task can be failed or manually marked as complete.

The valid Task Trigger values are system-supplied and are as follows:

 Add Attachment. This trigger requires an attachment of a specific type to be added to the
Change Request. Within a Change Request, the user will use the Add Attachments or
View Attachments button to browse for and add any accessible document as an
attachment, selecting an Attachment Type that will be used to determine if this task
requirement has been met.

 Add Hyperlink. This trigger requires a hyperlink of a specific type to be added to the
Change Request. Within a Change Request, the user will use the Add Hyperlinks or
View Hyperlinks button to take this action, selecting a Hyperlink Type value used to
determine if this task requirement has been met.

 Add Migration Note. A Migration Note is a set of information that describes any special
instructions or details associated with a migration request. The entry is made on the
Migration Note page in the CR component. The task is marked complete when a user
completes the entry of a migration note.

 Add Migration Request. A migration request will identify the set of objects to be migrated
by referencing a previously created Migration Set. The task is marked complete when a
user completes the entry of a migration request. The migration set must have been created
from the correct source database according to the workflow configuration in order for the
task to be marked complete.

 Add Note. This trigger requires a note of a specific type to be added to the Change
Request. Configure the required Note Type value associated with the control. Within a

Copyright @ 2020 Phire Inc. All rights reserved. Page 7 of 20

 Change Request, the user will use the Add Note or View Notes button add a note,
selecting a Note Type that will be used to determine if this task requirement has been met.

 Add Objects. When the user has successfully added an object to the CR, this task will be
marked as complete. Within a Change Request, the user will use the Objects page and
the Add PeopleTools Objects or the Add File Objects buttons to take this action.

 Add Script. When a user has successfully added a script to the CR using the Scripts page,
this task will be marked as complete.

 Add iForm. This trigger requires an iForm of a specific type to be added to the Change
Request. Configure the required iForm Type value associated with the control. Within a
Change Request, the user will use the iForms tab to add an iForm document, selecting an
iForm Type that will be used to determine if this task requirement has been met. For more
information on configuring iForms within Phire, refer to the reference document entitled
iForm_Builder.pdf.

 Add Task Comment. When a user has successfully added a comment to the Task
Comment page for this task, it will be marked as complete. This is done through the
Add Task Comment or the View Task Comments buttons on the CR Tasks page.

 App Designer Copy to Database. This task will create a PeopleTools project in the source
database (FSDEVL) and migrate it the target database (FSTEST) using the PeopleTools
Application Designer “Copy Project to Database” feature. The process begins when the
Execute button on this task is clicked and the task will be marked complete if it is
successful.

 App Designer Copy to File. This task will export the project associated with the CR to a
file using the PeopleTools Application Designer’s “Copy Project to File” feature. The
project is either the project from the last Phire proprietary migration, or the project created
by a preceding Create Project (PROJCRT) task. It also exports any DMS and SQL scripts
attached to the CR, as well as external file objects and migration notes that have been
associated with the CR. All the files are exported to a new directory specified in the
“Project Copy Dir:” field on the Domain setup page. The process begins when the button
is clicked to complete the task. If it is successful, the workflow will advance to the next
incomplete task.

 App Designer Project Build. This task will execute the Project Build feature of PeopleTools
Application Designer. The Target Database configured in the workflow will be the
database in which the project build is performed. The build settings can be specified at
runtime. When the task is performed as a step in the workflow of a CR, the associated
“psbuild.log” and “psbuild.sql” files are attached to the CR task and accessible through
the log button on the task .

 App Designer Project Compare. This task integrates with the “Project Compare” feature
of PeopleTools Application Designer. When the Execute button on this task is pressed, the
objects contained in CR will be used to generate a project in the source database and

Copyright @ 2020 Phire Inc. All rights reserved. Page 8 of 20

 compared against the target database, using the compare report settings from the
Windows registry for the user that started the Application Server process. The associated
output files will be attached to the task and made accessible through the “Migration
History” button on the task.

 App Designer Project Create. This type of task will create a PeopleTools project in the
Target Database using the list of associated objects. The process begins when the button is
clicked to complete the task. If it is successful, the workflow will advance to the next
incomplete task.

 Approval. This denotes that a task is an approval task and is made available in the CR
Approval component (Phire > CRs Home > CR Approval). It usually indicates a point
where the workflow can be advanced or failed back to an earlier step, depending on the
decision of the assignee.

 Create Migration Set. This task will be marked complete when a new Migration Set has
successfully been created for this CR from the source database. To create a Migration Set,
navigate to the Objects page in the CR, select the necessary objects in the list, press the
"Create Version Set" button, select the source database (FSDEVL), check the box labeled
"Migratable," and press OK. The Migration Set is the backup of objects intended for
migration at a later step or steps in the workflow.

 Create Version Set. This task will be marked complete when a new Version Set has
successfully been created for this CR from the source database. To create a Version Set,
navigate to the Objects page in the CR, select the necessary objects in the list, press the
“Create Version Set” button, select the source database, uncheck the box labeled
“Migratable,” and press OK.

 Enter Resolution. This type of task is automatically marked as complete when the
resolution on the CR is populated.

 Execute Script. This trigger marks the task complete when a script has been executed on
the Scripts page in the CR as the workflow requires. The workflow can be configured
with a target database, making it necessary to execute the script in the specified database
for the task to be marked as complete.

 Manual. A manual task is the simplest form of a task in the workflow. It is presented
with the associated button to complete the task and it advances the workflow when
clicked. Depending on the Pass Navigation setup explained below, the workflow will
either reset to the next available task or to one of the configured tasks.

 Migration. This trigger activates the Phire-automated migration feature to move the
associated objects to the target database. The Migrations page in the CR will contain a
history of the migrations that have been performed for this CR, and the user can use the
“Add” button to add the current migration to the list if it has not already been done. At
that point, the migration is initiated using the “Migrate” button on that row, triggering a
confirmation and starting the process. This task will be marked complete when the
migration has been completed with all objects successfully migrated.

Copyright @ 2020 Phire Inc. All rights reserved. Page 9 of 20

  Migration Set Compare. The task is marked complete when a Version Set compare is
executed using the Migration Set against the specified target database. Use the "Version
Set Compare" button in the header of the CR Objects page to complete this action. The
compare reports that are generated are attached to the task and made accessible through
the “Compare Result History” button on the task.

 Migration w/ Baseline. This trigger activates the Phire-automated migration feature to

move the associated objects to the target database. This feature also ensures the ability to
rollback the changes by automatically creating a Version Set from the target database prior
to beginning the migration. The Migrations page in the CR will contain a history of the
migrations that have been performed for this CR, and the user can use the “Add” button
to add the current migration to the list if it has not already been done. At that point, the
migration is initiated using the “Migrate” button on that row, triggering a confirmation
and starting the process. This task will be marked complete when the migration has been
completed with all objects successfully migrated.

 Multiple Approver/Owner. This task requires all the listed task approvers/owners to
approve the task before the CR can advance to the next task. For this task trigger, the
“Assignee Label” field is required and is a descriptive name that will be displayed on the
CR Assigned To field on the Task page. This value is used purely for informational
purposes and does not have any edits or drive any logic. The Approver/Owner list can
be specified for this task type. Any values entered in the Approver/Owner list will
automatically populate into the CR Task. If you have the “Assign Task” permissions on
this task type, you will have the ability to change the Approver/Owner list on the CR at
runtime. The approval or denial is performed by selecting the respective button on the
step in the CR Tasks page. All tasks defined as Multiple Approver/Owner appears in the
special CR Task Approval worklist page when the task becomes the current task.

The options for “Requirement” dictate how the approval will be managed. In each case,
the list of individual users is derived from the role(s) and user(s) populated in the
Approver/Owner list.

All Approvers Required. The approval will be complete when all approvers from
that list have approved.

One Approver Required. The approval will be complete when any one user from
the list approves.

One Approver per Role. The approval will be complete when one user approves
from each role, and any users that are unassociated with a role have approved.
Any user who appears in multiple roles can approve for each and every role that
they are a member of. If that user is in the list unassociated with a specific role,
then that approval is completed first. After that, a prompt is displayed showing
the list of roles for which the user can select to approve.

 Require Field Value. This task trigger is used to require a value to be entered in a CR field
that otherwise would not be required. For this task trigger, the name of the field to be

Copyright @ 2020 Phire Inc. All rights reserved. Page 10 of 20

 required needs to be specified in the “Required Field” in the workflow setup. This task
will be automatically marked complete once the required field is populated.
 Version Set Compare. The task is marked complete when a Version Set compare is
executed against the specified target database. Use the "Version Set Compare" button in
the header of the CR Objects page to complete this action. The compare reports that are
generated are attached to the task and made accessible through the “Compare Result
History” button on the task.

User Task Description

This button opens a page that includes a standard description of how the task will operate given
the information that has been provided. This includes references to the Task Trigger, Task Name
and necessary databases, note types, and so forth.

The long edit field is also available for you to enter information relevant to your specific business
process:

All of this information is presented to the user through the Task Information button, , which
is available on the CR Task page. The value entered in the configuration is rendered in the
browser as an HTML object, making it possible for you to embed HTML tags that will change the
presentation of the data. For example, wrapping text in the tags “<strong>” and “</strong>”
will make the text bold; “<font color=blue>” and “</font>” will make the text blue.

Note that the “View Sample” hyperlink displays the contents of your custom task information
rendered in HTML so you can see how it will look to users.

Copyright @ 2020 Phire Inc. All rights reserved. Page 11 of 20

This will make it easy to see the effect of any HTML tags included in the string for formatting
purposes.

CR Task Type
This value provides a way of characterizing the tasks at a higher level, such as “Development
Task,” “Management Task,” etc. The valid values for this are defined in the Application Code
Definitions page. The CR Task Type value determines the default assignment of CR Tasks and
determines CR Task security.

CR Status
This value represents the status that is assigned to the CR when the task becomes the current task
in the workflow. The overall status of the CR Status is determined by this setting and this field

Copyright @ 2020 Phire Inc. All rights reserved. Page 12 of 20

is required.

Issue Status
This value represents the status for any Issues related to the CR. This is an optional setting. It is
useful in installations in which the Issue module is implemented in conjunction with the CR. If
Issue Status values are configured, the Issue Status codes will be automatically updated as the
CR moves through the CR workflow.

Source Database and Target Database

The valid values for these settings are in the Database Definitions page of the Wizard. It controls
the processing of tasks that require database interaction, such as migration and versioning. If the
value is specified here in the workflow definition, then it is made part of the CR as a fixed value.
If left blank, then those tasks that require a database will have an entry-capable field on the CR
Task page, available to be specified in the CR at run time. In most cases, the migration path and
settings for this will be known and dictated by the workflow definition; however, the option is
available to defer the selections to the individual change requests.

Segregate Task
This option provides the ability to ensure a task is assigned to and completed by a user that is
different from the user that completed a prior task. A common example is that development
work needs to be “peer reviewed” before moving into the testing phase; essentially, the developer
cannot review his or her own work. While the developer may have the necessary permission in
Phire to complete the peer review step, this rule further ensures that they cannot complete the
step for a CR in which they are also the developer.

The configuration option is visible on workflow steps that allow for it, including those with
triggers: Manual, Approval, Migration, Migration with Baseline and Execute Script. The drop-
down list will contain the prior tasks from the workflow that are available to segregate against,
which includes any task that is not a Multiple Approver/Owner task or subject to a Master
Pass/Skip dependency.

To enforce the rule, select a previous task from the list and new Change Requests will begin using
the rule. The initial assignment of tasks will take the rule into account and discard assignments
that violate the rule. The steps may be assigned to the same role, but the steps still must be
completed or failed by different specific users. Information regarding this dependency is
presented if the current user attempts to incorrectly reassign, complete, fail or skip a step. If the
prior task is already completed, then the edit is performed against the specific user that completed
the task. If the prior task is skipped, then the edit is not enforced on the subsequent task. If the
current user has special permission to “Edit Any CR Data and Tasks,” then this permission will
override the Segregate Task rule and provide the ability to complete or fail the tasks. If the current
user has special permission to “Skip Any Task,” then this permission will override the Segregate
Task rule and provide the ability to skip the tasks. Information about the dependency is also
displayed on the Task Information page (see the button next to the step number).

Default User
When a CR is created, this configuration determines the assignment to the CR Task. Assignments
for tasks that do not have the Default User value specified are determined using the task
assignment logic as described in the document entitled Default_Assignments.pdf. The value

Copyright @ 2020 Phire Inc. All rights reserved. Page 13 of 20

can be set to:
 A specific user id
 A PeopleSoft role name
 %UserId, which automatically defaults to the current user when a CR is opened
 %Assignee, which invokes a custom view that allows you to provide a default user based
on custom logic
 %Customer, which resolves to the value entered in Customer on the main CR page

iForm Type
This entry field is made visible and entry capable only for tasks that have the “iForm” trigger
value. In these cases, this value is required and is used to determine the iForm Type necessary to
complete the task. For more information about configuring iForms, refer to the document entitled
iForm_Builder.pdf.

Attachment Type
This entry field is made visible and entry capable only for tasks that have the “Add Attachment
to CR” trigger value. This value is required for these tasks and is used to specify the Attachment
Type necessary to complete the task. Attachment types are configured in the “Application Code
Definitions” section of the Domain Setup Wizard.

Note Type
This entry field is made visible and entry capable only for tasks that have the “Add Note to CR”
trigger value. This value is required for these tasks and is used to specify the Note Type necessary
to complete the task. Note types are configured in the “Application Code Definitions” section of
the Domain Setup Wizard.

Hyperlink Type
This entry field is made visible and entry capable only for tasks that have the “Add Hyperlink to
CR” trigger value. This field is used to specify the Hyperlink Type necessary to complete the task
and the value is required. Hyperlink types are configured in the “Application Code Definitions”
section of the Domain Setup Wizard.

Allow CR Cancel
This checkbox indicates whether the “Cancel CR” button is enabled in the CR when this task
becomes the current task in the workflow (assuming the user has permission to cancel the CR).
Clicking the Cancel CR button will cause the CR to be canceled.

Allow CR Hold
This checkbox indicates whether the “Hold CR” button is enabled in the CR when this task
becomes the current task in the workflow (assuming the user has permission to hold CR).
Clicking the Hold CR button will cause the CR to be put on hold.

Allow Object Edits

This checkbox indicates whether changes to the CR Objects are allowed when this task becomes
the current task in the workflow. This is a control mechanism to prevent changes to the object
list after the CR has progressed to a certain point in the workflow, such as when it is out of
development. Un-checking this checkbox for all the steps after development will prevent changes
to the CR Objects unless the CR is failed back to development.

Copyright @ 2020 Phire Inc. All rights reserved. Page 14 of 20

Iteration Rule
Also referred to as the Subsequent Iteration Rule, this controls how the task behaves when the
workflow is failed to this task or a prior task. The options are:
1. Incomplete and Optional – this option makes the task incomplete on the subsequent
iteration and automatically adds the optional setting so that it can be skipped. Essentially
this makes the step repeatable, but not required on the subsequent iterations.
2. Incomplete and Required – this option makes the task incomplete and required again.
Essentially, this makes the step behave as it did the first time through the workflow.
3. Unchanged – this option leaves the task status and other aspects unchanged. That is, if
the step were previously completed or skipped, then it will remain so and will be
bypassed on subsequent iterations through the workflow.

Allow Script Edits

This checkbox is similar to the Allow Object Edits option but is referring to the CR Scripts page.
This is a control mechanism to prevent additional scripts or changes to script characteristics after
the CR has progressed to a certain point in the workflow.

Allow Manual Pass

This checkbox allows an automated task to be marked completed manually. If selected, a button
will be enabled on the CR Task when it becomes the current task so that the task can be marked
as complete without having to perform the required function. This option is only applicable to
automated tasks. As such, tasks defined by a MANUAL task trigger will have this checkbox
checked and disabled.

Allow Pass Anytime

Turning this flag on allows the task to be marked as complete by a user with proper permission
even when it is not the current task. This feature is useful when a task needs to be marked
complete out of order in the workflow. This option is only available for tasks defined with the
task trigger of MANUAL or APPROVAL.

Once this option has been selected, the additional After Step drop-down option will appear. This
allows selection of any prior task in the workflow. If left blank, the current step being configured
can be completed at any time, even out of order in the workflow as described above. But if a prior
task is selected, then the current step being configured will only become available for completion
after the selected task has been completed or skipped.

Unlock Objects When Complete

Select this option to have object locks automatically released when a specific task has been
completed or skipped. Regardless of the use of this flag, the original default logic is employed to
automatically release the locks when the CR is closed or canceled.

Pass Verb
The verbiage on the “complete” button shown on the CR Task page is derived from this setting.
The sample button images are shown to the right of this entry field. There are different verbs to
choose from and are generally applied on a task-by-task basis. For example, for an approval task,
you may choose to display the word “Approve”. For a testing task, you may choose to display
the word “Pass”.

Copyright @ 2020 Phire Inc. All rights reserved. Page 15 of 20

For tasks defined with task triggers MANUAL and APPROVAL, additional configuration is made
visible to specify an alternative target or targets for the task completion. When this task is marked
complete, the CR can be configured to route to the specified step instead of automatically
advancing to the next incomplete step in the workflow.

When a task is completed and there are no values specified in the “Pass Navigation” grid, then
the workflow will advance to the next incomplete task. If there is a value specified in the grid,
then the CR will be routed to the specified step. If there is more than one target step configured,
a prompt will appear to allow the user to select which step to make the current step.

The “Master Pass Step” field allows you to define dependencies to other steps. If a Master Step
value is specified, then the completion of the Master Step triggers the same completion on this
child step. The “Master Pass Step” field is only available on tasks with a task trigger defined as
MANUAL or APPROVAL. This field is hidden on tasks that are defined as a Master Pass Step
from another task.

Allow Fail?
This flag allows a task to be marked as failed in the workflow. A task can only be failed when it
is the current task. If a task can be failed, then the “Fail to Step” values are required and are used
to determine to which step the CR is routed. If only one target is specified, then the workflow
will route to that task when the fail button is clicked. If more than one target is configured, then
a prompt will appear to allow the user to choose. If the “Reason Required” is checked, the user
will be required to enter the reason for the failure.

Fail Verb
The verbiage on the “fail” button shown on the CR Task page is derived from this setting. The
sample button images are shown to the right of this entry field. There are different verbs to choose
from and are generally applied on a task-by-task basis. For example, for an approval task, you
may choose to display the word “Deny”. For a testing task, you may choose to display the word
“Fail”.

Optional?
This option allows a task to be skipped in the workflow. A task defined as optional will have a
skip button appear when it becomes the current task. If the skip button is clicked, the Skip
Navigation value(s) is used to determine which step becomes the next current step. At least one
entry is required for this configuration. If only one target is specified, then the workflow is routed

Copyright @ 2020 Phire Inc. All rights reserved. Page 16 of 20

to that task automatically. If more than one target is configured, then a prompt appears to allow
the user to make a choice. If the “Reason Required” checkbox is turned on, then the user will be
required to enter the reason for the skip.

The “Master Skip Step” field allows you to define dependencies to other steps. If a Master Skip
Step is specified, then the skipping of the Master Step triggers the same skip action to occur on
this child step. The “Master Skip Step” field is hidden if the task is defined as a Master Skip Step
from another task.

Skip Verb
The verbiage on the “skip” button shown on the CR Task page is derived from this setting. There
are different verbs to choose from and are generally applied on a task-by-task basis.

Workflow Databases
The Workflow Databases page is related to the workflow definitions and is used to identify the
databases that are available for various features throughout the Change Request process. This is
the Workflow Databases configuration page:

This list of databases entered in the setup page should contain at least the databases that are
included in the migration path for the CR Type. You can include other databases that are not
included in the normal migration path to enable ad-hoc migrations and script executions. For
example, you may have a training database that is not part of the normal migration path. Adding
the training database in this configuration and checking the “Ad hoc Migration” checkbox will
enable you to perform ad-hoc migrations to the training database.

Here is a summary of the features that are referenced for each database in this configuration:

 Enable Phire Object Locking

This option controls the list of databases for which objects will be locked from the CR.

Copyright @ 2020 Phire Inc. All rights reserved. Page 17 of 20

 Phire retains lock information for each database that has this option selected. If an object
is not locked in a database, Phire prevents migration of that object to that database. For
more information about the locking features in Phire, refer to the document entitled
Object_Locking.pdf.

 Add Object
This option controls the list of databases that are available when adding objects to a
Change Request. You may, for example, limit the list of databases when adding objects
to only the development database because that is where the code changes are made.

 Properties
The Object Properties feature is available from the CR Objects page and displays the
PeopleTools object properties. The list of available databases for this feature is limited to
those with this option selected.

 File Upload
File Upload is a feature that is available from the CR Objects page and provides a method
of uploading a file from the local directory to a server location based on the Database,
Server and File Directory configuration. This feature is useful if a developer has a local
copy of a Crystal or SQR program that needs to be uploaded to the development
PS_HOME folder. The list of available databases for this feature is limited to those with
this option selected.

 Object View/Download
File Download is a feature that is available from the CR Objects page and provides a
method of downloading an external file from the server location to the developer’s
workstation. This feature enables a developer to obtain a copy of files such as Crystal or
SQR program from production. This configuration determines the list of databases that
appear when the file download option is selected from the CR Objects page.

 Object Compare
Indicate if objects from this database are to be available in the Phire compare feature.

 Create VerSet
This option controls the list of databases that are available for selection when creating a
Version Set within the Change Request.

 Object Restore
This option controls the list of databases that are available for selection when restoring an
object or objects within a Change Request. The ability to restore objects is further limited
by user and role permissions established in Phire. For more information about Phire
security, refer to the document entitled Security_Administration.pdf.

 Ad-hoc Migration
Ad-hoc migrations can be performed within a Change Request at any time. The list of
available databases is limited to those with this flag checked. The ability to perform ad-
hoc migrations and restore objects is further limited by user and role permissions

Copyright @ 2020 Phire Inc. All rights reserved. Page 18 of 20

 established in Phire. For more information about Phire security, refer to the document
entitled Security_Administration.pdf.

 DMS Script Execute

This option indicates if this database is available for selection under the “Execute” button
on the CR Script page for attached Data Mover scripts. The ability to execute scripts is
further limited by user and role permissions established in Phire. For more information
about Phire security, refer to the document entitled Security_Administration.pdf. Note
that this flag does not control the option to execute scripts with a migration, only the on-
demand executions using the “Execute” button.

 SQL Script Execution

This option indicates if this database is available for selection under the “Execute” button
on the CR Script page for attached SQL scripts. The ability to execute scripts is further
limited by user and role permissions established in Phire. For more information about
Phire security, refer to the document entitled Security_Administration.pdf. Note that
this flag does not control the option to execute scripts with a migration, only the on-
demand executions using the “Execute” button.

Object Type Restrictions

In some circumstances, there may be a need to restrict the types of objects that can be
added/migrated through a CR. This is achieved in Phire through the Object Type Restriction
Rules. For example, you may want to prevent any security-related objects from being migrated,
such as “Menus,” “Permission Lists,” or “Roles”. In other cases, it may be necessary to limit the
workflow for certain types of objects, such as “Queries”. Once the restrictions are established,
the effect can be seen on the Add Objects page, where the list of available object types is limited
to those that meet the defined rule associated with the CR Type. This configuration is reflected
in open CRs immediately after setup is complete.

This restriction is associated with the CR Type, and is configured at: Phire > Administration >
Application Codes: Change Request Types, or on Step 3 - Application Codes in the Domain Setup
Wizard:

Copyright @ 2020 Phire Inc. All rights reserved. Page 19 of 20

The grayed-out icon, , indicates that there are no restrictions configured, whereas the
icon indicates that restrictions are configured for a given CR Type. Clicking the button opens the
detailed configuration page:

The overall implementation for the restriction is reflected in the Restriction Rule option that is
selected.

None. This is the default and essentially places no limit on the object types available to
the CRs using this Type. The only limit is based on the database selected at the time
objects are being added, and the list of object types available for that database at the time.

Exclude Selected Object Types. This option causes object types entered in the grid to be
excluded. This would be useful when the requirement is to exclude any security objects,
for example.

Include Selected Object Types. This option limits the object types available to those
entered in the grid. This would be useful when the requirement is to allow only certain
object types to be processed, for example.

The grid allows entry of the specific object types associated with the rule. The available list of
PeopleTools versions and object types are limited to the PeopleTools versions configured in the
PS Homes associated with the Domain page PS Home (found at Phire > Administration > Define
Domain).

Use the Clear button to easily clear the grid contents.

Use the Fill button to easily clear the grid contents. It will fill the grid with an entry for each
object type available for the PT version associated with the Domain. If multiple PT versions are
configured for the Domain, then a prompt is provided to select which PT version(s) to fill.

Copyright @ 2020 Phire Inc. All rights reserved. Page 20 of 20