Custom Properties defined in Project but not available for Day-2

[emacintosh]

We have defined some custom properties in our projects.  The goal is to use those properties during a Day-2 action.  But if I onboard a server to that project and run a day-2, those properties are not part of the __metadata_resourceProperties field in the payload. 

Should we not expect them to be there?  Isn't this a use case for that feature?  Is there any documentation on how/when those properties propagate to objects in a deployment.  Would this be considered a bug?  

I'm not sure if i'm just that bad at searching for answers or if the "it's a property for the project" type documentation is all we get.

[Ankush11s · Accepted solution]

It would be there for Aria Automation deployed VMs , Onboarding VM does not go through same lifecycle of events as deployed vms

[emacintosh]

Do you know if that's documented somewhere or is that just something you know from experience.

In any case, thanks.  I guess that will be one more feature we won't use, back to config elements.

[bdamian]

Do you mean that some actions must be available or not depending on the custom properties or you need those values in an script of a custom day 2 action?

[DanielStastka]

I created on Substription "relocation-service.deployment.onboarded" onBoard Workflow to add CustomProperties by onBoarding Process.  I have some "Custom Attribute" from vCenter to write back zu vRA vSphere Machine Ressources. 

I write two global action GetCustomProperties and SetCustomProperties (over RestAPI). I think is more stable if VMware something change the Payload. 

On end, i create a 2-day (vSphere.Machine) Workflow to change Metadata thats write back on vRA/vAA, vCenter and Active Directory

[emacintosh]

We need them to be sent in the payload for a day-2 action so that we can act on them in our various workflows.

We also add some custom properties when oboarding servers, but those are more like status flags.  I just don't understand why I'm putting properties in a project to just turn around and have to put them on the deployment resources again later myself.  I'm definitely not going to onboard to a project, then read the projects properties and then put those properties on a resource.  That's a lot of hoops for little benefit.  

I'm sure there are other ways to get there as well, but in that case we'll just create project config elements and put the properties in there.