All posts in Office365

Manipulating REST API Calls in SharePoint Designer 2013 Workflows

In my previous post on the different ways to determine the return message from a REST API call in a SPD workflow I covered using a test list and Fiddler to build your web call in a SharePoint Designer workflow.  In this post I want to discuss manipulating REST API calls in SharePoint Designer 2013 workflows.  Basically I want to show how you can determine what your read string is going to look like based on the values coming back from SharePoint.

Read more

Handling REST Responses in SharePoint Designer Workflows – Reading The Response

Years ago when Microsoft released it’s latest version of SharePoint Designer, it came with a few enhancements that really made building workflows with Designer more robust and efficient.  One efficiency enhancement was the ability to copy actions, steps and even entire stages within the same workflow or even between workflows.  Microsoft also allowed for the ability to move back and forth between stages instead of continuing down a parallel path (called a state machine workflow).  While the addition of state machine workflows to Designer (previously only available in Visual Studio workflows) is great; in my opinion the best (by a very small margin) addition to Designer is the ability to call web services.  As your queries get more and more complex however, knowing what is coming back into the workflow can be filled with frustration as you try to determine how to get the data from the response content.  While I it isn’t a new concept, I wanted to discuss handling REST responses in SharePoint Designer workflows.  Or at least how I do it.  The method I use is pretty straight forward and very easy to implement.

Read more

Waiting in a SharePoint Designer 2013 Workflow

All too often when building workflows in SharePoint Designer there is a need to pause the workflow for a duration of time, or while waiting for values to change within SharePoint list\library.  Microsoft has provided methods or actions within a workflow to accommodate this for quite some time.  The method to accomplish while similar between versions has changed with the latest iteration of SharePoint Designer.  For this reason I wanted to discuss waiting in a SharePoint Designer 2013 workflow today.  I know that most are now moving to SharePoint 2016 or SharePoint online, but while Microsoft has released newer versions of SharePoint, it hasn’t released a new version of Designer since 2013.  So whether you are on SharePoint 2013 or a later version, this post is relevant for the foreseeable future.

Read more

Modifying the PowerApps Display Styles Based on Field Values

By default, browsing items in a list with a PowerApp the items all look the same.  This is fine in most cases, but I want to ensure the managers viewing the items can see items that are older first.  I could do this by modifying the search parameters for the browse screen to put the oldest at the top, but I want the older ones to jump out a bit.  So right now logging in, a user is going to see this:

Modifying the PowerApps Display Styles Based on Field Values - Default View

I want to modify the view so that the text of each is a different color depending on the age of the request and also how close the request start date is from the current date.  So initially I want the colors set based on the following criteria:

  • If less than 7 days old: Green
  • If more than 7, but but less than 14: Yellow (<– Yellow on white background is hard to see)
  • If more than 14 days: Orange
  • If the current day is less than 21 days from the start date: Red

This is where conditionals come into play.  Like all programming languages, PowerApps allows you to use conditional statements to control objects.  If…then…else, switch statements, etc are all available to allow you to conditionally manipulate your environment.  In this case I want to use conditionals to control how the text will appear.

The format of an IF conditional is If(<Condition>,<then>,<else>) or If(<Condition>,<then>,<elseif condition>,<then>,….)

For example: if I wanted to use an if statement for the text color of the user’s name I would put the following formula on the color attribute:

Today() is a function similar in function to Date.Now().  So what the statement above states is if the item created date is within the last 7 days, change the color to green.  Applying the function to the above list items will give us the second item as green for the Name field:

Modifying the PowerApps Display Styles Based on Field Values - Formatting The Name

If I wanted to do show a couple of my options above I would need to use an if\elseif conditional.  So for the Green and Yellow conditional I want:

Modifying the PowerApps Display Styles Based on Field Values -  Multiple Conditionals

So that’s just two conditionals.  As you can see it could get pretty long.  I would love to say that we could move to a switch statement using something like this:

However, currently only comparisons to constants will work. For instance if you did a math calculation of “NumDaysDif = Today() – ThisItem.Created” and had a result of 5 you could then do this in your switch statement and get the result you want:

Unfortunately this is not an option currently.  So to accomplish what I want to do I need to write a long if statement.  The final statement will look something like this:

And when added to all of the fields in the Browse Gallery your result should look something like this:

Modifying the PowerApps Display Styles Based on Field Values - All Fields Updated

Pretty straight forward once you get going.

 

Thanks for reading!

 

Using SharePoint Lookup Type Fields in PowerApp Browse Screens

In my previous post I discussed how to create a new PowerApp directly from a SharePoint list.  I also indicated it had a few limitations that needed to be addressed.  One of these limitations was the default browse screen is not compatible with lookup type fields (People\Groups, Choice, Lookup, etc).  These field types are of course available in the details and edit screens, but not the browse screen.

Using SharePoint Lookup Type Fields in PowerApp Browse Screens - Bad User Experience

I can force the control to look at the field I want, but it doesn’t know how to convert the object into text.

Using SharePoint Lookup Type Fields in PowerApp Browse Screens - spUser Not Compatible

Being limited to just the text fields of the list or at least fields PowerApps knows how to treat as text (Date\Time fields) was creating a bad user experience in the forms I wanted to create. I had to come up with another way.  Using a calculated field in the SharePoint list won’t work because a calculated field can’t see those columns either.  It’s actually

Using SharePoint Lookup Type Fields in PowerApp Browse Screens

Because I want to be able to see these values on my browse screen they need to be converted to text.  The two fields I want on my browse screen that are not compatible with the view are:

  • Training Requested For – The name of the person taking the training (Person or Group field)
  • Training Requested – Title of the training course (Lookup Field)

Luckily there are formulas that can help us out here.  To display the name of the user PowerApps has the ability to call the DisplayName property of the field.

Using SharePoint Lookup Type Fields in PowerApp Browse Screens - Display Name of Person Field

To get the title of the training requested is just another property of the field.

Using SharePoint Lookup Type Fields in PowerApp Browse Screens - Displaying Lookup Field

I decided to get a bit fancier and add some text at the beginning of the value to add to the experience.  I wanted the field to read: Course Name: <“Name of the Course”>.  To do this, you simply combine two strings together (the can be variable based or static (what you typed)) inside a Concatenate function.

The final values I wanted on the form were the start date, End Date and total estimated cost.  Dates were straight forward as they are available from the drop down of the data properties.  The cost I had to get a bit fancy here too.  I wanted the cost to display as Total Estimated Cost: $XXXX.XX.  The problem now is that the Concatenate function requires strings and the TrainingCost field comes back as a numeric.  Enter in a another formula.  Text(<string>, formula) will convert a string to a formula.  The final formula looked like this:

When all was said and done I ended up with my form looking like this”

 

PowerApps is still pretty new, but there is a lot you can do with it.  I look forward to seeing where it will get to in the near future.

 

Thanks for Reading!