RC1 Update 3 adds a new Null function, which (to me) sounds like it should flow a null value into the destination attribute. I have a case where i am flowing a date from SQL into the metaverse. Just for testing, I tried a basic flow of:Null()->employeeEndDateThis seems to function the same as this:""-employeeEndDateBoth will add the employeeEndDate attribute to the metaverse object with a blank (not null) value. To me, Null() seems like it should be equivalent of mventry("employeeEndDate").Delete, but it doesn't seem to. Ultimately, what I want is to flow the value in if it is present in my connector space, and delete it if it is not. Something like this:IIF(IsPresent(TermDate),DateTimeFormat(TermDate,"yyyy-MM-ddTHH:mm:ss.000"),Null())Anyone have any thouse on this? Is there an easier to way to do this that I am overlooking?Thanks,Keith

The IIF implementation is an "If...Then...Else".The objective of the Null function is to have an equivalent for "do nothing".So, it is more a Null function than a Null flow.With the null function, you can configure an IIF tha's just an "If... EndIf" without the Else part.Cheers,Markus Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Thanks Markus, that definitely clears up the Null() function for me. But using the portal-based rules, how can I acheive my desired result of deleting the value in the Metaverse if it becomes null in the connector space?Thanks,Keith

It depends of your SQL.If your data column can be null and if it become like this, import it from your SQL to the MV will delete the value in MV.However, if you reimport the employeeEndDate from the FIM Portal to the MV, which means you have 2 sources for the employeeEndDate value, I guess the MV will keep the old value based on the one of FIM Portal.Point to test.

That depends on the setup.However, you are right, the question is who is authoritative for the attribute? "how can I acheive my desired result of deleting the value in the Metaverse if it becomes null in the connector space?"In general, by Flowing the null value into the metaverse Enabling null flows in the EAF rule to FIM You also need to adjust your attribute flow precedence settings to enable the external resource to own the value.Cheers,MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Null flows are enabled, and the flows are such that it is all one way (HR -> MV -> Portal). If I directly flow the attribute it works fine and deletes the MV value, but the dateTime format in SQL doesn't match that of FIM (though the MV allows it) so I had to put an expression on the inbound flow to convert it to the proper format. If I do this:DateTimeFormat(TermDate,"yyyy-MM-ddTHH:mm:ss.000") -> employeeEndDateIt works properly for users with a value in TermDate; when the value is null it seems to flow an empty string the MV (and then errors out when it goes to the portal). If use an IIF statement (in my initial question) I get the same result. Basically, what I need is if the there is a value, convert it and if not, delete it from the MV. For now, I have decided to flow a ficticous date if the value is null in the connector space (9999-12-31). In order for other things to function properly, I need to create two sets, one for users with that attribute populated and one without. if i use the dummy value and compare it to today's date, those sets become temporal, which I really don't want.Thanks,Keith

Any update to this... Again, have to go back to classic rules... Joe Stepongzi - Identity Management Consultant www.microsoftIdM.com,ilmXframework.codeplex.com

I don't have any update on this. Haven't played with it in a while though either. I'm hoping that maybe something was introdcued in Update 1, but aside from that, you are right - classic rules. Seems to me that the ability to force the deletion of an attribute through the "codeless provisioning" would be a common need. I can think of lots of clients in the past where I ran into cases of "If X then flow, if not X, then delete". Keith

Yes.. this is pretty huge actually, I had to scrap codeless because of the numerous issues I am seeing with it.. Precedence fails tremendously, causes random allow nulls, and will not join on outbound flows either.. One of my very large clients and I decided to just use the old coded way, it was causing too much time wasted trying to figue what was not working and it would always point back to codeless.. pretty disappointing.. Hopefully the team is going to provide some significant updates soon.Joe Stepongzi - Identity Management Consultant www.microsoftIdM.com,ilmXframework.codeplex.com

So here is a new update on this, with somewhat of a workaround. I ran into a scenario where I wanted to delete attributes upon removal of a sync rule. Unless I am missing something, this can't be done normally. When my sync rule is removed, the attributes are no longer flowed from the MV to the CS, but they aren't removed from the object in the CS either. My Scenario: Only certain users should flow their location info to AD for display in the GAL. My Solution (these aren’t the real Set/Rule/WF/MPR names, it just makes it easier to understand): 1. Create two sets: “Show Info” & “Hide Info” 2. Create Sync Rule: “Flow info to AD” a. Dependent on a Sync Rule “AD Base” 3. Create Workflow “Apply Flow Info to AD” to apply “Flow Info to AD” Sync Rule 4. Create MPR to apply the “Apply Flow info to AD” Workflow on Transition In to “Show Info” 5. Create a new Metaverse attribute for people called “nullString” 6. Create Sync Rule: “Null Info to AD” a. Dependent on “AD Base” b. Flows the nullString attribute to all AD attributes that need to be blanked out 7. Create Workflow “Remove Flow Info to AD” to remove “Flow Info to AD” Sync Rule 8. Create Workflow “Apply Null Info to AD” to apply “Null Info to AD” Sync Rule 9. Create MPR to apply “Remove Flow Info to AD” and “Apply Null Info to AD” Workflows on Transition In to “Hide Info” set. Obviously, you’ll need a null MV attribute for each data type you need to blank out, but it works. I haven't tried it, but it's likely this could also be done on inbound flows, provided you have unused attributes of each type in your data set (with a view you could just create them). If X, then flow regular attribute from the CS in to the MV; if not X then flow the "null" attribute from the CS into the MV. Keith

As I think about this more, after creating the nullString attribute in the metaverse, I can do the following in my outbound base rule for any given attribute: IIF(<Should Show Info>,physicalDeliveryOfficeName,nullString) --> physicalDeliveryOfficeName WAAAYYY easier…. no additional Sync Rules, Workflows, MPRs, etc. Like I said earlier, this could also be done on inbound flows, provided you have unused attributes of each type in your data set (with a view you could just create them). Keith

Keith, This was a useful. I needed to clear the manager attribute as users are off-boarded (not deprovisioning from a FIM perspective because the AD objects are still being managed). An MA Extension DLL wasn't helping very much as I would need to know what FIM sync rule triggered the export flow for an advanced flow rule for manager. i.e. I didn't want to clear the manager attribute for all outbound flows. Therefore, I created a new attribute in the FIM schema called nullDN, bound it to the person object, added it through the Metaverse Designer to the person object in the old ILM UI, and flow nullDN to manager in the off-boarding sync rule in FIM. During an export to AD, you can see that the manager attribute is actually cleared. Steve

Keith, This was very helpful. I needed to clear the manager attribute as users are off-boarded (not deprovisioning from a FIM perspective because the AD objects are still being managed). An MA Extension DLL wasn't helping very much as I would need to know what FIM sync rule triggered the export flow for an advanced flow rule for manager. i.e. I didn't want to clear the manager attribute for all outbound flows. Therefore, I created a new attribute in the FIM schema called nullDN, bound it to the person object, added it through the Metaverse Designer to the person object in the old ILM UI, and flow nullDN to manager in the off-boarding sync rule in FIM. During an export to AD, you can see that the manager attribute is actually cleared. Steve