PDXpert PLM Software
On-line Help Guide

This help topic describes the current PDXpert PLM release. Earlier releases may be different. To view your release's version of this topic, open PDXpert and press the F1 key or select the Help menu.

Change forms

Collection Explorer ◢ Changes group ◢ Change Forms collection

Change forms should be Completed, Canceled or Rejected before editing their related Change Forms member. A new change form's workflow, participants and some collection member attributes are copied from this template to the change form. New settings may not affect previously-created change forms, or may have unexpected results.

Other users should not be using the system while you're working. Close all item records in your workspace before you begin. Close the PDXpert client and start it again when you've finished.

Purpose §

Classifies changes according to their usage; sets or enables options; manages standard approval and email notice lists; defines workflow and custom properties.

Where used §

Change form

Data fields §

Some data fields show a character counter in the upper right of the box. This is helpful for editing a custom label, and for data that may be exported to other systems that limit imported text length.

General §

Name §
This is the complete name for the change form, such as Change Notice or Production Deviation.
Display name §
The abbreviation is used extensively in identifying the change form. This is typically CN, Dev and similar industry terms (up to 10 characters in length).
Description §
This gives the change form and its purpose.
Show Files list §

When this checkbox is marked, the Files list is visible. Files and external links can be added to the change form.

If any files have been attached to change forms, and then this checkbox is cleared, the Files list – and attached files – is hidden. The files are not deleted. To ensure visibility and access, this checkbox must remain marked after it is set.

Active: users can select
Default member of collection
Permanent member of collection §
See the Managing collections: Common attributes help topic.

Attributes §

Item number §

These settings define how the change form's Number is assigned.

User assigns number §

When this checkbox is marked, the use must enter the change form's Number at the time the change is created. The selected Identifier sequence is ignored. In most cases, this checkbox is marked only when a different computer system gives the change number, and you must coordinate releases with the other system.

Identifier sequence §

Specify the change number generator for the change form. This selection is disabled if the User assigns number is marked.

You can choose a single identifier sequence for all ECRs, ECNs, RFDs, etc., or you can designate a separate sequence just for ECRs, a different one for ECNs, etc. For more information, refer to the Sequences: Identifier collection.

Use a single identifier sequence for all change forms. You'll avoid confusion between overlapping change numbers, such as ECR 1234 and ECN 1234.

Analyst label §
This textbox lets you match an analyst's role to the change form. For example, the analyst for a design change may be labeled as Design Analyst while the analyst for a purchased part release is Component Engineer.
Default analyst §
This dropdown list box lets you select an analyst for the change form. The default analyst can be overridden when the originator makes a new change form. If the selection is empty, then the change form's analyst is (a) the originator if that person has an analyst role; or (b) any other person who has an analyst role; otherwise (c) the super administrator. Changing this value will not affect change forms that have been created.
The persons in the list have a Roles collection member that includes Is an analyst. If you later remove the analyst role from this person, update this value with a new analyst.
Affected list accepts documents §
Affected list accepts parts §
When these checkboxes are marked, items of the specified class may be added to the change's Affected list.
Pause at Released state §

When this checkbox is marked, the accepted change is stopped at the Released state before it can be moved to Completed. The Product Team attributes can be edited and items on the Affected list can be dispositioned. After the released data is updated, the analyst can move the change to the Completed state, where it's locked.

If this checkbox is not marked, then the system immediately moves an accepted change to Completed without pausing at Released. Workflow notices are sent only to the email recipients specified in paths 14 and 24 (all email checkboxes for path 25 are cleared).

Release/Cancel iterations on Affected list §

Unless this setting was not set correctly during setup, do not change it after you begin using this collection member. This setting is copied to each change form instance when the change was originated; an existing change form won't use the current value. Before modifying this setting, finish processing all change forms based on this collection member.

When this checkbox is marked, the change form is an executing change form. When (1) all reviewing groups have approved the change and (2) the system or an analyst moves the change to the Released state, then each iteration on the Affected list is released (if previously pending) or canceled (if previously released).

When not marked, the change form shows a future intent (like a Change Request) or temporary status (Deviation, Waiver, Stop Ship) to change an item. It doesn't have any effect on an Affected item.

A new Change Forms collection member does not show the following two settings. An existing (upgraded) collection member shows these only when they don't match the Release/Cancel iterations on Affected list value. These two settings will be removed in a future PDXpert release. Set them to match the Release/Cancel iterations on Affected list value.

The following two settings are no longer supported. When the Release/Cancel iterations on Affected list value is changed, or if all three values match, then the following two settings are immediately and permanently hidden.

Show iterations on Affected tab §
Mark this checkbox when you want item iterations to be shown on, and affected by, the change form (notably, releasing and/or canceling iterations using a change notice). Clear the checkbox to provide a general notice about the item, regardless of the iteration (for instance, a Change Proposal or Stop Shipment).
Show releasing/canceling icon §
When this checkbox is marked, the Affected list shows each iteration as getting Released or Canceled. When cleared, the released change won't affect the affected item's release status.
This checkbox is automatically marked for executing changes. It's always cleared for information change forms (e.g., change request/proposal, waiver, deviation, stop ship).
Show a Person #1 role §

This checkbox shows a principal person for the change form. For example, you may want users to identify the responsible creator, such as design engineer, on the change.

If this checkbox is cleared, then the person #1 dropdown list isn't shown on the change.

Person #1 role label §

The textbox lets you label the person's responsibility. For example, you can use Design Engineer as the label on the change.

Show a Person #2 role §

This checkbox shows another principal person for the change form. For example, you may want to identify the responsible user, such as project manager, on the change.

If this checkbox is cleared, then the person #2 dropdown list isn't shown on the change.

Person #2 role label §

The textbox lets you label the additional person's responsibility. For example, you can use Project Manager as the label on the change.

Show Problem source selection §
When this checkbox is marked, a problem source dropdown list box is shown to the change creator. Manage this list using the Problem sources collection.
Display Change reason selection §
When this checkbox is marked, a change reason dropdown list box is shown to the change creator. Manage this list using the Change reasons collection.
Show a starting boundary §

When this checkbox is marked, user can view and modify the change's starting date and/or serial number fields.

Starting boundary label §
This value is shown to identify the starting date as, for example, Begins on.
Show an ending boundary §

When this checkbox is marked, user can view and modify date, total quantity and serial number fields that show the change's duration or limit. Specifying a completion or expiration point (date, serial number or quantity) is often required for advisory changes, such as deviations and stop-ship orders.

Ending boundary label §

This value is shown to identify the ending point as, for example, Ends after or Resume shipments.

Clearly indicate whether the change period ends before, or after, the date entered by the change author.

Participants list §

Reviewing groups §

The Reviewing groups list shows who is responsible for reviewing a routed change form. The list is copied to each new change form, where the groups and email order can be edited further.

If there's no one listed on a group's Persons list, then the group can't be added to a change form's Reviewing groups list. Read more about reviewing groups in the Groups: Change form reviewers help topic.

Add to the Reviewing groups list by dragging a group from the Groups collection on the Collection Explorer.

  • The Order specifies when email notices are sent for a routed change: lower-valued groups (for example, 1:Engineering) receive an email notice before higher-valued groups (say, 2:Production) get their email notice. More than one group can have the same Order number, and there can be gaps between the values.

    The Order is a convenience for later reviewers, but it doesn't restrict when reviewers can respond. When the change form is routed, all groups' reviewers immediately see the change in their Item Explorer Tasks list. Trailing reviewers can jump ahead and respond before receiving their email notice: for example, to clear review tasks before vacation, or to promptly disapprove the change so earlier reviewers don't waste their time.

    The most efficient review scheme is in parallel; that is, set every group's Order to 1.

  • You can specify whether Participation is required or optional. The change workflow waits for reviewers who Must act. A reviewer who Can act is free to approve, disapprove or ignore the change. After all required reviewers have responded, the workflow proceeds without waiting for the optional reviewers' responses (unless the Can act reviewer has Held the change).

    Groups that are set as Can act should be notified early in the workflow order. If they're notified after all Must act groups, the change is released before they're notified.

  • Set the reviewing group to Locked so that its participation can't be deleted from the change form.

To delete a reviewing group: select the row ► , and press your keyboard's Delete key.

Observing groups and persons §

Persons with valid email addresses, even those without a user log-in account, can receive email notices during the change workflow. You can designate when these observers are informed of a change's progress using the lifecycle states map in the Workflow page. This list is copied to a new change form, and can be further modified on each change form.

  • To add a group observer, drag the group's name from the Groups collection of the Collection Explorer onto this list.
  • To add a person observer, drag the person's name from the Persons collection of the Collection Explorer onto this list.

Delete an observer by clicking on it, and then pressing your keyboard's Delete key.

Workflow §

The workflow map enables workflow paths between a change's current state and the next enabled state. The map also specifies which groups of users are notified as the change moves through the approval workflow.

The workflow diagram shows all possible lifecycle states. For each lifecycle state, you can (a) enable or disable the workflow paths to other states; and (b) identify the user groups that should receive an email notice when the change moves to that state.

Workflow diagram paths §
Workflow paths are buttons 01 to 25. To enable a path between two workflow states, click on the path button, and set the Enable workflow path checkbox. If you disable a particular path, then the change can't move to that lifecycle state. The originator and the analyst are shown on the change form's General page.

Path definitions:

  • 01 [ORG→ORG]: The originator or the analyst selects a user as new change originator.

  • 02 [ORG→SUB]: The originator or the analyst submits the change form to the analyst who, after a quality check, routes it for approval on path 05.

  • 03 [ORG→RTD]: The originator or the analyst routes the change form to reviewers for approval. If the change has been previously routed, all reviewer responses are reset (comments are retained).

  • 04 [SUB→ORG]: The analyst returns a submitted change form to the originator for further work.

  • 05 [SUB→RTD]: The analyst routes the submitted change form to reviewers for approval. If the change has been previously routed, all reviewer responses are reset (comments are retained).

  • 06 [SUB→CAN]: The analyst cancels the change form, which the analyst can then delete.

  • 07 [RTD→ORG/SUB]: The analyst removes the routed change from review, and returns it for further work. All reviewer responses are reset to pending. (Note 1)

  • 08 [RTD.disapprove→ORG/SUB]: After any reviewer has disapproved the routed change, the system returns it to the originator or analyst. (Notes 1 & 2)

  • 09 [RTD.disapprove→REJ]: After any reviewer has disapproved the routed change, the system rejects it and retains it as a permanent record. (Note 2)

  • 10 [RTD.disapprove→STP]: After any reviewer has disapproved the routed change, the system stops it and waits for the analyst. (Note 2)

  • 11 [RTD.disapprove→CAN]: After any reviewer has disapproved the routed change, the system cancels it, which the analyst can then delete. (Note 2)

  • 12 [RTD.approve→RTD.approve] (always enabled): After all reviewers in the review order (for example, 1) have approved the routed change, the system routes the change form to the reviewers in the next review order (say, 2). Path 12 defines who gets an email notice when the change moves from the previous set of groups to the next set.

  • 13 [RTD.approve→ACC]: After all reviewers have approved the routed change, the system accepts it and waits for the analyst. (Note 3)

  • 14 [RTD.approve→REL]: After all reviewers have approved the routed change, the system immediately releases it. (Note 3)

    Path 14 is a fast-track replacement of paths 13 and 24. The change form is released only if the affected items' relationships remain valid.

    However, if the change has an error—for example, an affected item now relies on a canceled reference item—, then the system sets the change form's lifecycle to Accepted, and email notices are sent as specified by path 13. The analyst resolves the error by (a) correcting the problem (say, by releasing a new iteration) and then releasing the change via path 24; or (b) correcting the change form via path 23. Therefore, when using path 14, set emails for path 13 and 24 to respond to errors.

  • 15 [RTD→CAN]: The analyst cancels the routed change form, which the analyst can then delete.

  • 16 [RTD.pending→HLD]: A "can act" reviewer blocks the release of the routed change form.

    The analyst (not the reviewer) must move a change form out of the Held state. If the analyst moves the change directly to Routed (path 18), then all previous approvals are retained. The reviewer who held the change remains selected. If the analyst moves the change to Submitted (path 17) and then to Routed, all previous responses are reset.

    Do not enable this path if all of your reviewing groups' participation is set as Must act. For Must act reviewing groups, the change is always blocked from release until a response is provided. The Hold change response is intended for Can act reviewing groups, to prevent the Must act reviewing groups from releasing the change.

  • 17 [HLD→ORG/SUB]: The analyst takes the held change form from the reviewers. All existing reviewer responses are reset. (Note 1)

  • 18 [HLD→RTD.pending] (always enabled): The analyst returns the held change form to the routed state.

  • 19 [HLD→CAN]: The analyst cancels the held change form, which the analyst can then delete.

  • 20 [STP→ORG/SUB]: The analyst withdraws the stopped change form. All existing reviewer responses are reset. (Note 1)

  • 21 [STP→REJ]: The analyst rejects the stopped change form and retains it as a permanent record.

  • 22 [STP→CAN]: The analyst cancels the stopped change form, which the analyst can then delete.

  • 23 [ACC→ORG/SUB]: The analyst withdraws the accepted change form. All existing reviewer responses are reset. (Note 1)

  • 24 [ACC→REL] (always enabled): The analyst releases the accepted change form, which may update the release status of affected items.

  • 25 [REL→CMP] (always enabled): The analyst completes the released change form after all dispositioning tasks are closed. When the change is completed, all data fields, except the Notes page, are locked.

    Approved changes can be set to automatically move from Released to Completed. In this case, emails are not sent using path 25. See the Pause at Released state checkbox setting.

Notes

  1. When the path ends at […→ORG/SUB], the change returns for rework to the selected state:

    • When the Return to Originated path is selected, then the change form always returns to the Originated state.

    • When Return to Submitted path is selected, then the change form always returns to the Submitted state.

  2. Paths 08/09/10/11 are mutually exclusive; for example, setting path 10 automatically disables the other paths.

  3. Paths 13/14 are mutually exclusive; for example, setting path 13 automatically disables path 14.

  4. Some paths are always enabled, and the Enable workflow path is locked. For example, moving a change into Accepted always requires an exit (path 23 or 24).

Send emails to: §
Mark the corresponding checkbox to identify the parties who are notified when the change moves to a different lifecycle state.

  • Originator This is the person who made the change, and has principal authority for modifying (or deleting) it. This role is similar to a document or part trustee.

  • Reviewers in all groups All authorized approvers of every listed group. The person must be listed in the Persons list on the Groups member form, and the group must be on the change form's Reviewers list. The email notice is sent without regard to the groups' responses (Pending, Approve, Hold, Disapprove).

  • Reviewers in pending group(s) All persons who are authorized to review on behalf of a listed group where the group's current response is Pending.

  • Holding reviewer The person who sets a group's response to Hold.

  • Reviewers in active group All users who are also reviewers for the current reviewer's group.

  • Observing persons Persons identified on the change form's Observers list.

  • Analyst The analyst who is named on the change form. This analyst can edit the change, add/remove file attachments, and change the workflow lifecycle states.

  • Analysts The group of all persons who have been given an analyst role. Analysts may change the change's workflow, and select a different named analyst. Analyst roles are specified within a Roles collection member when Is an analyst is marked, and that role is then selected for a Persons collection record.

  • Reviewers in next group(s) All authorized approvers for the next group(s) as specified by the Reviewing groups' review Order. Email notices are only sent where the next group's response is Pending.

  • Disapproving reviewer The person(s) who have set the group response to Disapprove.

  • Product team All members of Product Teams with affected items on the change.

Custom list §

You can define custom attributes (or "properties" or "extensions") to the system-supplied attributes for each change form. A change form's custom attributes are on the change's Custom page.

Before working with custom attributes, refer to the Custom attributes help topic for important information.

Text Templates §

Primary discussion label §
Label the primary discussion field based on how it's used. For example, you may want to label the field as Problem description or Solution summary depending on the change form you're defining.
Primary discussion text template §
When a new change form is made, the change form's primary discussion field is automatically loaded with this text value, which the user can then edit. Providing your users with a good change discussion template ensures that your change forms are clear, concise and valid. A good template enhances completeness and consistency, which makes finding, reviewing, and releasing a change form easier.
Show secondary discussion §
When this checkbox is marked, the change form shows a field (with your label) on the change's Attributes page; this is used for auxiliary change information.
Secondary discussion label §
This value is shown to label the secondary discussion field based on how it's used. Depending on the change, you may want to label the field as Rework instructions or Production impact.
Secondary discussion text template §
When the change form is made, the change form's secondary discussion field is automatically loaded with this text value, which the user can then edit.

Setup §

Executing and advisory change forms §

PDXpert distinguishes between two categories of changes. Executing changes (like change notices) will affect the status of documents and parts listed on them. Executing changes cannot be routed if the system finds a problem with an affected item, such as canceling an iteration that's still on a released parent item. Advisory changes (such as change requests) propose changes, yet even upon release won't update the items on the Affected list. See the Processing a change help topic.

You specify an executing change by marking Release/cancel iterations when change is released. If you make a change based on an executing change form and put a document or part to the change's Affected list, then that item's status is updated when the change form is released.

Workflow states & paths §

The diagram shows all change lifecycle states. Each change form moves from one state (say, Originated) to a different state (Routed) along an enabled workflow path (path 03). When the change moves, it can notify persons affected by the new state.

Change workflow diagram

Notes regarding workflow states:

  • The Submitted and Accepted states let the analyst confirm that the change form has been reviewed correctly. Submitted provides the opportunity to make sure that the change form meets internal standards for completeness and accuracy, while the Accepted state lets the analyst make sure that reviewers' comments don't conflict with the change form's release. If the organization doesn't require such intermediate reviews, then disabling path 02 and enabling path 14 provides the shortest workflow.

  • In smaller organizations, a disapproved change invariably is reworked and then re-routed for approval; it's therefore common to enable path 08. In more complex reviews, the change form can be disapproved for a variety of reasons, and therefore enabling path 10 offers the most flexible recovery.

  • Reviewers with participation set as Must act should keep the Response in Pending state until they're ready to approve or disapprove. Reviewers with participation set as Can act may use the Held state to block the change from leaving the Routed state while they investigate the change. If your Reviewing groups list doesn't include reviewers set as Can act, disable path 16 and rely on the Disapprove paths 08 to 11. When enabling path 16, keep in mind that the reviewer requires the analyst's assistance in moving the change back to Routed.

  • Moving a change into the Canceled state lets it be permanently deleted from the system. The other terminating states, Completed and Rejected, retain a permanent record of the change.

  • In the Released state, the dispositioning attributes can be modified and closed; in the Completed state, these attributes are locked.

2012