Update Occupant Features returns warning: Occupant assignment(s) could not be processed.

[SamuelMonat]

Hello,

After doing the tutorial, I'm trying to use the Update Occupant Features tool with a csv file containing only two lines for two occupants on a units feature layer. I checked that both values in the UNIT_ID field are an exact match with the units features as well as for the USE_TYPE, OFFICE_NAME, FACILTY_NAME, LEVEL_NAME, LEVEL_NUMBER and VERTICAL_ORDER fields. Yet, when I run the tool, two lines are added in the occupant features as expected, but nothing shows up on the map and all of the fields are empty. I get this warning: 2 occupant assignment(s) could not be processed. 

Is there something that can cause the match between UNIT_ID values to fail?

Thanks!

[Zrobinson_SFPUC]

Hello, did you ever resolve this issue? Having the same problem here.

[Zrobinson_SFPUC]

I was able to resolve this issue with Esri Support. The problem was that I had "null" values in the Assignment Type field of my Units layer. Once we calculated all of the null values to None values, then the tool worked as expected. 

[JaceBrown]

Hi,

I ran into the same issue. To get a successful import, I included only the following fields in my "Input Occupant Table:" Known As, Email, Site ID, Contact Phone, Job Title, Org_Level_1, Org_Level_2, Start Date.

Furthermore, I left the "Unit Identifier (Input Occupant Table)" blank. These changes resulted in a successful import.

I was also attempting to assign the occupants to specific Units and Levels based on their respective IDs located in the Indoors attribute tables. However, those attempts resulted in repeated failures. I believe that functionality may be reserved for Indoor Space Planner in ArcGIS Online.

[AaronKoelker]

I'm running into a similar issue as well, but none of the suggestions so far have worked for me. The weird part is I have two (supposedly) identical copies of my Indoors Database (fgdb) and feature classes, and it works on one set and not the other. 

About half the occupants match and the other half do not. In the text log that the GP tool generates the message for each that doesn't match is: example@email.com could not be assigned to 'xyzxyzxy' because the unit's ASSIGNMENT_TYPE value is not None or Office, or the unit does not exist in the input Units layer.

The matching Unit IDs are there, I can even search them exactly from the input table to the Units table and get a match. There are no leading or trailing space. And the Assignment types are all Office or None, but I even tried setting them all back to None. Truncating the Occupants and trying again also results in the same issue. None of the units have a Null Assingment Type, either. 

[SophieFrank]

Hi Aaron, 

When you calculated the Assignment Type field to None, did you use the string "None" or the domain code "none". If the former, could you try calculating the field to "none" to match the domain and see if you still face the same issue?

[AaronKoelker]

Hi @SophieFrank 

I did use the lower case 'none' domain code when calculating the values, and afterward in the attribute table in showed the domain description 'None', so it seems to have been setting the domain value correctly. 

For now, I ended up just copying the working copy of the FGDB I had. Hopefully it was just user error somewhere along the line, but I've run out of ideas and need to move on.

Thanks