Super Contributor.. skbd Super Contributor..
Super Contributor..

Downstream Impacts

This may be simple or complex - not sure which it will turn out to be, but I am attempting to implement a new generic application deployment request and workflow.

As part of this template, we want to create a validation which will contain a 'table' of other applications which would be considered as dependant upon the application being modified and are thus labeled as 'downstream impacts'.

I want to be able to select one or more of these in an automated fashion when the application being modified by this request is selected.

I want each of the downstream impacts to include notification to an SME for that application who would determine what the impact would be.

Choices for this would be like:

1) None

2) Low impact - changes needed but are independant

3) High impact - changes are needed and must be coordinated with the first change


I would like the low impact changes to spawn a child CR for that application with no dependancies to the 'parent' CR

I would like the high impact changes to either spawn a child CR with dependancies OR create a 2nd package within the same CR... not sure if possible at this point.


I believe I know how to create the validation that would give me the necessary impact relationships, but I was curious if anyone else has done something similar to this and what mechanisms they put into place to make it work?


Essentially I am broadening my own personal brain-storming session to anyone else who would care to contribute!

3 Replies
Super Contributor.. skbd Super Contributor..
Super Contributor..

Re: Downstream Impacts


After additional research, my original thoughts are not looking terribly workable...

I have set up a validation - a Drop-down list - which contains a listing of all of our various apps and under the description of the table, I have a simple listing of all other applications which can impact this one.

Then I created a second validation - an Auto Complete list - which scans the KNTA_LOOKUPS for any applications in which the targeted app shows in the Description column.

On the request, I created a field (using the 2nd validation above) which allows multiple selections for the downstream impacts.

Problem here is that you cannot do any decision-making in the workflow based upon a multi-select field such as this is.

I dont want to create a separate yes/no field for every app as we have a few dozen and it would be very ugly indeed.

Back to square one...

Erik Cole Acclaimed Contributor.
Acclaimed Contributor.

Re: Downstream Impacts

Thinking out loud here...

At a previous employer we set up a quick-and-dirty CMDB by creating a custom "Application" request type with basic name, owner, category, each app had a request in the system open indefinitely (and maintainable by the owner) or until retired.

ACL validations had SQL that queried the request tables for this request type.

Sounds like you already have this info in a DDL validation though.

What about a table component? Have a custom workflow step populate a table component with rows (App/Owner/Impact) for all the apps that are impacted by the request. Impact would be your "none/low/high" DDL and the value would need to be selected by each app's owner.

At the same time that the table component gets set, also use the same data to plop all the owners' names into another text box on the form. Use this text box's token in a "Approve (All Users)" workflow step where each person would go into the table component and set the value for Impact for their app, then "vote" approved. When all owners are done, the request can move forward...

Super Contributor.. skbd Super Contributor..
Super Contributor..

Re: Downstream Impacts

Hey Eric - Thanks for the input!

I was looking into using a table component yesterday - problem is I am very inexperienced at doing that.

I am a team of 1 and have had no formal training, so I don't always comprehend the best approaches or know what to do with the ideas I have!   🙂


I really want to automate as much of this as possible so as to reduce mishaps and this sounds like a good approach.

As to the perpetually open request...  this 'master' request would contain the information regarding the downstream impacts as well as owner/contact info, correct?


That is a cool idea - I hadn't even thought in that direction!


Let me know if I am grasping this correctly and thanks again!


The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.