When
using Microsoft Flow to trigger on SharePoint list items I often use
the Initialize variable actions to get the values of my fields. You
could of course use Dynamic content at any stage of your flow, but when
you play around with the initialize variables you will find some maybe
unexpected behaviours.
First of all I created a SharePoint list with one field for each field type.
Then I created a flow with a that initializes multiple variables.
Yes/No
Then the first field that I looked at Yes/No shows quite nicely the way the Dynamic content behaves:
As
you will have noticed my Yes/No field from my trigger is available as
are all the other Boolean type fields from my trigger. This depends on
the Type selected in my initialize action.
Number
Then
I tried the Number field and I found that the expected Integer type
didn’t offer me the Number field that I created on the list. I had to
select Float as my type before I could set a variable to my number
value.
Person
Then
the next field. A Person field gives you an even more unexpected
behaviour. When you select the String type you get multiple parts of the
Person field presented as data:
The following data is available to use:
- Person Claims
- Person Department
- Person DisplayName
- Person Email
- Person JobTitle
- Person Picture
But don’t forget that you have ore options. When you select the Object type you will get also a Person object:
Note:
The object dynamic content only displays the above ones you have
selected String as a type and the inputs have been loaded. This seems to
be a minor bug where selecting Object initially doesn’t load the data
properly.
When running the flow you will find that the same data is returned in an object format as Dynamic contents already offers you:
Did
you notice the value-key-item-output Dynamic content earlier? This is
probably the right place to have a look at that one as well. When
loading this into an Object variable you will find a complete json
representation of you trigger item. So once you understand how to query
json in flow you can create your Expression based conditions quite
quickly.
{
“@odata.etag”: “\”2\””,
“ItemInternalId”: “1”,
“ID”: 1,
“Title”: “Title”,
“MultipleLinesOfText”: “B81BCC989\”>This is some gb(180, 85, 0);\”>formatted textms-rterangecursor-start\”>rangecursor-end\”>“,
“Number”: 1234,
“YesNo”: true,
“Person”: {
“@odata.type”: “#Microsoft.Azure.Connectors.SharePoint.SPListExpandedUser”,
“Claims”: “i:0#.f|membership|pieter@pieterveenstratriaddev.onmicrosoft.com”,
“DisplayName”: “Pieter Veenstra”,
“Email”: “pieter@PieterVeenstraTriadDev.onmicrosoft.com”,
“Picture”: “https://pieterveenstratriaddev.sharepoint.com/_layouts/15/UserPhoto.aspx?Size=L&AccountName=pieter@PieterVeenstraTriadDev.onmicrosoft.com”,
“Department”: null,
“JobTitle”: null
},
“Person#Claims”: “i:0#.f|membership|pieter@pieterveenstratriaddev.onmicrosoft.com”,
“Modified”: “2018-04-20T10:34:04Z”,
“Created”: “2018-04-20T10:34:01Z”,
“Author”: {
“@odata.type”: “#Microsoft.Azure.Connectors.SharePoint.SPListExpandedUser”,
“Claims”: “i:0#.f|membership|pieter@pieterveenstratriaddev.onmicrosoft.com”,
“DisplayName”: “Pieter Veenstra”,
“Email”: “pieter@PieterVeenstraTriadDev.onmicrosoft.com”,
“Picture”: “https://pieterveenstratriaddev.sharepoint.com/_layouts/15/UserPhoto.aspx?Size=L&AccountName=pieter@PieterVeenstraTriadDev.onmicrosoft.com”,
“Department”: null,
“JobTitle”: null
},
“Author#Claims”: “i:0#.f|membership|pieter@pieterveenstratriaddev.onmicrosoft.com”,
“Editor”: {
“@odata.type”: “#Microsoft.Azure.Connectors.SharePoint.SPListExpandedUser”,
“Claims”: “i:0#.f|membership|pieter@pieterveenstratriaddev.onmicrosoft.com”,
“DisplayName”: “Pieter Veenstra”,
“Email”: “pieter@PieterVeenstraTriadDev.onmicrosoft.com”,
“Picture”: “https://pieterveenstratriaddev.sharepoint.com/_layouts/15/UserPhoto.aspx?Size=L&AccountName=pieter@PieterVeenstraTriadDev.onmicrosoft.com”,
“Department”: null,
“JobTitle”: null
},
“Editor#Claims”: “i:0#.f|membership|pieter@pieterveenstratriaddev.onmicrosoft.com”,
“{Identifier}”: “Lists%252fAllSorts%252f1_.000”,
“{Link}”: “https://pieterveenstratriaddev.sharepoint.com/_layouts/15/listform.aspx?PageType=4&ListId=8317c539-1506-4a32-a84e-447bed9e22f4&ID=1&ContentTypeID=0x01008F2ED88AA63A6640A64719BF65EBF976″,
“{Name}”: “Title”,
“{FilenameWithExtension}”: “Title”,
“{Path}”: “Lists/AllSorts/”,
“{HasAttachments}”: true
}
Date
Then
now the next type of field. The Date field is another strange one. The
Initialize Variable only offers Boolean, Integer, Float, String, Object
or Array. What do I do with my Date?
The String type offers me the Date.
Choice
The choice field is another one where the Dynamic content help you getting to the actual data.
Lookup
The lookup fields are always causing problems when coding SharePoint fields. Time to put flow to the test
In
my example I’m creating a lookup to the list that I’m testing all the
fields with. Additionally I’m making multiple fields available within my
views on the list.
We could just go for the techy option here using a string variable and set it to the following Expression:
@triggerBody()?[‘Lookup_x003a_Date’]?[‘Value’]
But there is an easy way just select the Dynamic content again after you selected the String as the variable Type
Conclusions
The
different type of fields in SharePoint can all be handled. I found a
few times that as I added list columns that Flow didn’t pick up the
changes until I closed and opened my flow again. This can be a real
pain. Also when you can’t find the data that you are looking for the
json queries can help you find the data that you want. Worst case switch
over to the Object variable type just to help you understand the data
structure that is returned.
