Caution: Articles written for technical not grammatical accuracy, If poor grammar offends you proceed with caution ;-)

In Part 1 and Part 2 of this series, we created three inputs for our vRealize Automation blueprint: Production, WordPress, SOX compliance. These three inputs correspond to property groups that allow us to associate multiple custom properties to a single input. Using property groups allows us the ability to templatize how each input affects the outcome of a request. In this article, the Genie that we’ve previously released from the proverbial bottle is about to take form, as we walk through how these three inputs come together to determine the outcome of our request.

Let’s look at how the different input options impact the different modules.

Module Environment Application Compliance Convention Outcome(Prod, WordPress, SOX) Naming Prod = pDev = dLab = l WordPress = wpMSSQL = ms None = nSox = s {{env}}{{app}}{{comp}} pwps IPAM Network Prod = prodDev = devLab = lab Wordpress = webMSSQL = db None = nullSox = sox {{env}}{{app}}{{comp}} prodwebsox vCenter Folder Prod = PRODDev = DEVLab = LAB Wordpress = WORDPRESSMSSQL = MSSQL None = nullSox = SOX \{{env}}\{{app}}\{{comp}} \PROD\WORDPRESS\SOX vSphere Tags ProdDevLab WordPressWeb ServerMicrosoft SQLDatabase No ComplianceSOX Compliance See vSphere tagging below ProdWordpressWeb ServerSOX

To read the full article please visit the SovLabs Blog here.