We have never experienced that behavior. That is quite strange. If you have a single blueprint entitled to one business group and request it from that business group, it should go in that business group. (Even if you have it available in another business group)
We do things differently. We allow for a group to deploy machines in any business group, but they do it through a XaaS Blueprint that then uses a service account that has the entitlement to all the business groups. The service account in this strategy acts like the person in your strategy. We have not seen an issue with this as you describe. The service account can deploy the blueprint into any business group it is entitled to do so.
I mocked up your example though, and when I created your scenario... the behavior is as you desire. This Win blueprint deploys in both business groups for me as a support user. (our RHEL builds are offline in lab right now, but that should be irrelevant)
I am a support user in each BG, and I am entitled to the same catalog item once in each BG. I deploy from each.
I get both of them in the items tab because the FILTER is set to ME as the owner.
But one is in BG A and one is in BG B.
These are also XaaS requests. I'm launching a workflow which gathers the user input and then submits a request to launch the composite blueprint. In my situation though I'm giving the users the entitlement to the composite blueprint, but not assigning it to a service which keeps it from showing up on the request portal. In the end though, it sounds like it's basically the same configuration you're using except it's the user account which directly has access to the business groups rather than a service account.
Here's my results.
This is my service catalog which clearly shows I have the CentOS 6 blueprint available for two groups; Infrastructure and IT Operations.
I use the Infrastructure catalog item to request a server named TestVM1, and I use the IT Operations catalog item to request a server named TestVM2.
I end up with both being deployed under Infrastructure.
However, if I disable the Infrastructure reservation then both items will provision to the IT Operations business group.
Sorry. I am a little confused by your explanation.
1. You have a XaaS Blueprint that is entitled to the user.
2. A request of this blueprint takes in values that fulfill a server request--to include Business Group (subtenant reference)--and it runs a workflow (inside the XaaS workflow) to make a request for an IaaS Blueprint that is entitled to the user in multiple business groups? (So you are running something similar to "Request a catalog item on behalf of a user" -- using the passed user credential?)
3. The IaaS blueprints are entitled to the user, but they do not show up for the user? That is a strange condition. How are you doing this? I know of one way with a services hack.
The two items you have in the image. These are IaaS blueprints, correct? If you click request on each one individually... they deploy in the first business group and it's associated reservation consistently? Or are you saying that when you run the XaaS Composite Blueprint... it does so?
If it is the "Composite" blueprint, are you sure that you are getting the correct Catalog Item target?
For example, I could see a condition where I end up calling this Catalog Item twice from a XaaS blueprint, when I think that I am calling the one on top first and then the second one second.
I just want to make sure that this is absolutely true...where you say "use" here... you are talking about clicking the "Request" button on the IaaS Blueprint Catalog Item shown in the picture?
"I use the Infrastructure catalog item to request a server named TestVM1, and I use the IT Operations catalog item to request a server named TestVM2."
To clarify:
1) The catalog item in the screenshot in my prior reply is an XaaS blueprint.
2) This XaaS request takes in user and server specific information such as server name, server size, server category (dev, prod, etc.), username to be created, password, etc. I have a predefined vCACCAFE:CatalogItem defined which points to an IaaS blueprint. The workflow gets the request object, modified some of the data, then submits it.
// Get the provisioning request for the catalog item
var request = vCACCAFERequestsHelper.getProvisioningRequestForCatalogItem(catalogItem);
// Get the provisioning request data for further manipulation
var requestData = vCACCAFERequestsHelper.getProvisioningRequestData(request);
var jsonData = JSON.parse(requestData);
// ---------- Do some other things here
// Add the request data to the provisioning request
// System.log("New requestData = " + JSON.stringify(jsonData));
vCACCAFERequestsHelper.setProvisioningRequestData(request, JSON.stringify(jsonData));
// Submit the request
result = System.getModule("com.vmware.library.vcaccafe.request").requestCatalogItemWithProvisioningRequest(catalogItem, request);
3) The whole process I'm using to hide the IaaS blueprint is as follows:
1. Publish the IaaS catalog item to a service.
2. Entitle the user to both the item and the service the item belongs to. (At this point the IaaS catalog item shows up in the request portal.)
3. At this point I'm able to assign this blueprint to my workflow. (See screenshot below)
4. Now I go back to my service in vRA and remove the IaaS blueprint from the service.
At this point, my XaaS workflow can still get the request and submit it and my user is still entitled to the IaaS workflow, but it no longer shows up in the request portal.
