Understanding publish statuses in process management

A process has one of four distinct Publish Statuses, which follow its typical lifecycle.

• Development — Used during initial process configuration, development, and unit testing. In Development mode, the system sends the requester all tasks plus all notifications for assigned tasks and general notification tasks. Notifications from the Dynamic Notification task still go to the configured address.
• Testing — Used after unit testing and for a wider audience other than the process developer. All users assigned receive proper notifications, but these statistics don’t count toward future reporting.
• Production — Used when the process is live and available for your end users.
• Inactive — Used when a process is decommissioned and a new version of a process has been published to Production. The Inactive status enables existing requests against that process definition to complete normally, but nobody can start a new request against it.

New processes start in Development. Publish status and role memberships together determine who sees and runs the process. Process Testers have Run and Participate access in Testing, and Process Users have those permissions in Production. Process Administrators and System Administrators have different permissions across publish statuses. Check role membership before assuming that changing status alone controls access.

Replace a live process safely

1. Keep the replacement in Development while configuring it. Check Dynamic Notification destinations before starting test requests.
2. In Process Detail > Role Memberships, assign designated testers to Process Testers. Review Process Users before release. See set roles and permissions for the access each role grants.
3. Move the replacement to Testing for a wider test. Verify that testers can start it, assigned users receive notifications, and regular users can’t start it without Testing access. Testing statistics don’t count toward future reporting.
4. Move the tested replacement to Production. Confirm that intended Process Users can start it.
5. Set the old process to Inactive. Existing requests against it can finish, but users can’t start new ones.

Publish status can also be used when reviewing request activity in My Requests, Manage Requests, and Monitor Requests views. This helps teams filter request lists by Development, Testing, Production, or Inactive workflows when they need to triage requests across environments.

Replace a production process safely

Use this checklist when you promote a replacement process and retire the old process.

1. Add testers to the role that can see and run processes in Testing. For more information, refer to the roles and permissions guide.
2. Set the replacement process to Testing and run test requests. Testing activity doesn’t count toward future reporting.
3. Check all notification tasks. For Dynamic Notification tasks, use test recipient addresses until the replacement process is ready for Production.
4. Set the replacement process to Production only after tester signoff.
5. Set the old process to Inactive so users can’t start new requests from the old definition.
6. Verify that old in-flight requests continue to completion and that new requests start only from the replacement process.