Change Requests
To initiate the request, the stakeholder completes a form and submits it as a record. This change request then moves through a series of states and actions. The state of a change request is its current status. Typical states include submitted, assigned, duplicated, or closed. An action is an activity that moves a change request along. Typical actions include assign, reject, validate, resolve, and close.
This figure shows how a defect might move through the change request process. An end user submits the change request. A development manager assigns it to a developer and it remains in an open state until the developer makes a decision about the defect. If the developer chooses to fix the defect, it is given a resolved state. At that point, a quality engineer looks at it and validates that it is actually fixed and working. Then, the quality engineer changes the state from resolved to closed.

Information about a change request is recorded and stored as a record in a user database. A user database contains different types of records for different projects and purposes. Each record type has unique fields and data requirements. For example, a project might have a record type for defects and another for new feature requests. If many records with similar input are used within a development environment, it is often useful to create a record template for each record type. When this template is used to create a new record, the common fields are automatically populated based on the record type.