The problem with 'i' s in SharePoint
- Tony Ogilvie

- 2 hours ago
- 2 min read
So came across a really weird series of issues recently when creating SharePoint fields that I figured I'd share.
I created a set of simple text fields for use in a SharePoint Lookup List with 8,000+ rows.
Adhering to my 'KISS' (Keep It Simple, Stoopid) principle, I created each field with initial Display Names of ICL1, ICL2, ICL3 and so on. Ugly, yes, but my aim was to create the fields with simple Internal Names of ICL1, ICL2 etc, that I could then change the Display Names of to something more user friendly.
Should be simple right? Sigh ... NOPE!
SharePoint - for some weird reason - encodes that initial letter 'I' when generating the internal field names. So the instead of getting my expected internal names, the actual internal names were generated as shown below:
Display Name | Expected Internal Name | Actual Internal Name |
ICL1 | ICL1 | x0049_CL1 |
ICL2 | ICL2 | x0049_CL2 |
ICL3 | ICL3 | x0049_CL3 |
Well, that's a bit irritating, I thought, but I can live with that weird quirk.
.... but then it got worse!
I needed to create a Power Automate which retrieve items from the lookup list, filtering on these fields using an ODATA Filter Query.
Should be simple, right? Just use the weirdly encoded Internal Names in my Filter Query like this, right?

... but once again ... it was not to be that simple!
It turns out ODATA Filter Queries don't like fields which start with an _ underscore - so the above query failed, even though I was using the correctly encoded internal name of the field.
The solution: You have to prefix ODATA_ to the encoded field name, as shown below:

Obvious, eh?! Instead of filtering on what i assumed would be ICL3 , I had to filter on OData__x0049_CL3 instead 🥴
So - the moral of the story is - avoid creating Field Names in SharePoint with the Letter 'I'! And if you do, be prepared for some configuration gymnastics as shown above to get them to work right!
Comments