Target system mapping with type none should be excluded from actionContext.Data
in progress
Twan Duvigneau
Fieldmapping types with the type none cannot be seperated from actual mapped fields with a $null value. This is very confusing and makes it a bit of a strage mapping type to use. The purpose of a field with mappingtype none would be to return the data from a target using the script, and not set it. It would be way more logical to not provide the fields in the actionContext, because they should not be set. But keep them in the outputContext because they do need to be returned.
R
Rick van den Dijssel
in progress
Planned April release
R
Rick van den Dijssel
This will be changed with the April release where the behaviour is that the fields with type none will be excluded from the actionContext.Data but are still available in the outputContext.Data. This so we can see the difference between a field with mapping type none and a field with source mapping for which the value is null.
We detected a single github target connector (entra id) for which this change results in different behaviour. These instances will be automatically changed in HelloID in the week before the release. So the release should not effect the functionality of this connector.
R
Rick van den Dijssel
Merged in a post:
ExportData in Powershell v2
Niek de Melker
In the new powershell target, ExportData is calculated in the fieldmapping. This works great except for custom information. Sometimes you want to add a value that the system gave to you on create, or the field can be changed manually in the target system but has no update in the script.
For example you could want to store the account GUID, but you don't want to define it in the field mapping.
Another example will be in scope of the google and KPN target systems, there you want to calculate an UPN or email address which should not be updated by HelloID, but if this value is changed in the target you want to safe the value from the source in HelloID, just like the build in AD systems. This however seems to not be possible in V2.
R
Rick van den Dijssel
Niek de Melker It seems to me that there are two issues that you try to address. The first one is having value to store which has a value which is generated by the target system itself. The other one is to keep up with manual changes of attributes in the target system. Is this correct?
If this is the case for the first issue we have a solution. You can add a field in the mapping with the mapping option of "none" this means the field has no input value but a output value is excepted. With this you can just update the $Output.Context.Data.Field to be the generated account GUID as example.
In the second case we don't have support for this. It's also something we currently think we want to address in Reconciliation in the future (the difference between de state of HelloID and the target system state also on attribute values). But this is our current tough and could change overtime.
Niek de Melker
Rick van den Dijssel: Thank you for the reply. you are correct about what I want. After reading your reply I got some extra thoughts on this and remembered you can add multiple mappings on a field for the different actions. So the UPN can have a complex mapping on create, and a None mapping on update.
This could be the way to a solution, the only problem with this is that the UPN field still is provided in de
$ActionContext.Data
and $OutputContext.Data
with the value of Null
, and no way for the script to know if it should clear the value in the targetsystem or not. Other mapped fields can also be Null and should be cleared for example. If there is a way for the script to know the fields of Type None a full solution for me can be made. maybe with something as $ActionContext.FieldTypes
of $ActionContext.NoneFields
, or leave the fields gone in the $actionContext.Data
and available in the OutputContext.The reason I want this is so I can make the target system as reusable as possible. In this example I used UPN, but this can also be any other field, like description or whatever.
Niek de Melker
Thinking of it, it would be cool if the field in the mapping is create only, and on update presented in the
$OutputContext.PreviousData
, this value will be stored in HelloID.