How do I keep track of Admin Staging migrations with Integrity?

This has been a question which gets asked of PTC Support time and again. Unfortunately there is no *good* way to do it with out-of-the-box Integrity functionality so I am making this blog post to share with everyone what one of our largest Workflows and Documents customers has done. If you have worked with Integrity for some amount of time, you know that if you can dream it, you can build a system to track it.

Attached is a Powerpoint presentation outlining the basic set-up of one customer's process with a few redactions and rewording to remove sensitive data. At a high level, here is what they did:

1. Created a new type to hold data about each admin object in the system (Admin Objects).
2. Created an IBPL field backed with those items to make a nice drop-down list of objects to choose when tracking their changes.
3. Created a couple types to track the user requests and actual configuration work details ('Change Request' from end users and 'Integrity Dev Task' for the admin team to break-down the work needed for the change. These are related to each other.).
4. When working on an Integrity Dev Task, admins could enter data like which objects would be affected by the change, estimated implementation date, user priority, a quick summary, and a long text field for more detailed notes. There is also a place to put actions to perform before and after the migration (ie removing inactive pick list values from active items).
5. When changes were pushed from Dev to Staging, other admin members would test and verify that the changes did not break any common operations which use those objects. There are fields on the dev task to indicate passed/failed testing and comments.
6. There are many more small details which I will not go into (like using triggers to validate certain field data).

All of this is great since they had leveraged Integrity functionality to audit their changes and gain these benefits:

• See who made what changes, to which objects, and when using queries/reports.
• Easily adapt the process to meet changing admin needs since the solution is controlled entirely by the admins.
• Replaced their old, MS Word sneakernet-based process where documents were emailed around and was prone to mistakes.

Using Integrity like this is good but it is really addressing a need that most of our customers have and is not met by native product functionality. If you are an organization which uses the Admin Migration process, you will most likely want to contact PTC Support to be attached to the following Requests For Change (RFCs):

• 98068 (This RFC asks for the ability for Integrity to better control admin object changes in a similar way to how Integrity handles source code management. A change package style of item or object to contain all of the object changes, for example)
• 135839 (This RFC asks for a way to review details about an admin migration after it occurs. Currently there is no way to go back and report on migrations.
• 115366 (This RFC asks for the ability to export pending admin object changes to a file prior to actually migrating them)
• 104542 (This RFC asks for a new audit logging category to track just admin migrations. Currently, admin migrations are only tracked if all "admin" events are enabled. mksis.auditor.im.admin=true in is.properties)