Product epic DataScope and MgmtScope fields are blank in recently created epics.

[ladonnaq]

For most new products, onboarding and creation of their first release plan is now self-service (no contact with the SDK onboarding PM team). Currently, the DataScope and MgmtScope is blank in the Product Epic. Since we are not meeting with or reaching out to the self-service teams these fields need to be always populated with the same value as Triage work item. This is impacting our new PowerBI reports for APEX.

Requirement: When a new product onboards, the DataScope and MgmtScope field values need to be updated based on the onboarding information.

• If a service is onboarded vs product, update the fields in the epic-type product that is created as part of the release planner automation.

Data integrity: The Product epic owns this data after onboarding and should always be accurate. The triage data reflects initial baseline during onboarding.

• If the DataScope and MgmtScope are manually updated during onboarding, then the PM team will manually update the fields in the product Epic.
• If a service partner onboards a product again and the DataScope or MgmtScope has changed, then also update the fields in the Product epic, as well as triage.

### Tasks
- [ ] Manually update Product epic DataScope and MgmtScope for epic type product that have blank values.   (La Donna)
- [x] Update existing automation to update DataScope and MgmtScope field values when the epics are created during onboarding. (Engineering)

[maririos]

@ladonnaq I didn't understand

If a service is onboarded vs product, update the fields in the Service epic and the Product epic "placeholder" created during onboarding.

When I see is that the Service/Product epic in the Service tab doesn't have a field for management plane or data plane because a service can have both, right? and it depends actually in the product. So if I understand correctly, we shouldn't do anything if a Service (only) onboards, but when a product onboards then also update the Product epic

[maririos]

Follow up with La Donna about duplicaiton on Triage workitem

[ladonnaq]

@ladonnaq I didn't understand

If a service is onboarded vs product, update the fields in the Service epic and the Product epic "placeholder" created during onboarding.

When I see is that the Service/Product epic in the Service tab doesn't have a field for management plane or data plane because a service can have both, right? and it depends actually in the product. So if I understand correctly, we shouldn't do anything if a Service (only) onboards, but when a product onboards then also update the Product epic

Correct there are no DataScope or MgmtScope in the service tab of the Epic work item. When a service is onboarded, there is an epic for a "product" created by the release planner automation. For example, here is the triage work item for Quota RP service - https://dev.azure.com/azure-sdk/Release/_queries/edit/17717/?queryId=a62cc8c4-1c88-4982-b1ff-a2c35ad1528f. Here is the epic-product type for Quota RP - https://dev.azure.com/azure-sdk/Release/_queries/edit/17717/?queryId=a62cc8c4-1c88-4982-b1ff-a2c35ad1528f. For the "service only" scenario, I would like the "epic-product type" DataScope and MgmtScope values updated.

[maririos]

As part of this issue we have stopped sending information to the Triage work item about management and data plane scope. This is to avoid duplicating data and making sure it is in the right place

[maririos]

Triage work item template now has the management and data plane scope fields hidden. We decided not to delete to not break existing processes

[ladonnaq]

@maririos - There has been an unintended bug introduced by the changes. It appears that the "Create a release plan" feature is determining the product scope from the DataScope and MgmtScope in the triage work item. A service partner just pinged me for help because she could not create a release plan. I just unblocked her by changing the Triage work item template to show the MgmtScope field. However, since ADO does not retain field values that have been hidden, I had to manually update the value of the field in the triage work item to unblock the service partner. We need to have this resolved as soon as possible, because every user is going to be blocked from creating a release plan.

[maririos]

reverting and deploying to PPE now

[maririos]

so what should be the flow? that the release planer checks the properties in the product itself instead of the triage work item?

[ladonnaq]

so what should be the flow? that the release planer checks the properties in the product itself instead of the triage work item?

I do not the know the exact implementation on the backend but that approach should work. Let me know when changes are in PPE and I will test before you deploy to PROD.

[maririos]

I do not the know the exact implementation on the backend but that approach should work.

I am not asking for implementation details. In terms of requirements, a user onboards. We save that information in the triage work item and the product work item. During informational meeting, you verify the information is correct. and if it is not you update the information in both places (risky.... as manual intervation is error prune).

When a user is going to create a release plan, where should automation validate the scope. The triage work item? or the product work item? I am thinking the triage work item.

But then the question is, why do we have the duplicate information in the product if no one is using it?

[maririos]

We talked offline with @ladonnaq and we are going to move logic to use the product information instead of the triage information. Before making the changes though, we are going to look at other places where we might have a dependency on this fields and address it