Action statistics in Office 365

By: Vladi Gubler | Comments [0] | Category: Administration | 10/24/2017


We are introducing new statistics indicators to help you understand the performance impact of your actions (and eventually alerts, item IDs and import profiles). With the new indicators you will be able to monitor how many times an action gets executed per day and what is its average execution duration. This way you will be able to identify problematic actions that exert potentially unnecessary workload on your SharePoint and could be subject to throttling both by us and by Microsoft.

When you enter the action settings page, you will notice two icons for each action:

The left one indicates how many times the action executed today (we will be adding historic data chart for the last 7 days). The indicator changes color to yellow and then to red as the number of executions grows.

The indicator on the right displays the average execution time for long-running actions. Only actions that run over about 80% of the throttling limit are included in the average, so it's ok for the value to stay at 0 seconds for most actions, it doesn't mean they do not run, just that they finish quickly enough not to be included in the average. Note if your indicator shows up as red, it means the action gets throttled (almost) every time it runs and it should be reconfigured to lower its workload. For instance, a timer-based action should probably have more precise conditions and not attempt to update too many items at the same time. Throttled actions do not complete their work and some of your items could remain untouched.


Modern UI Support in Ultimate Forms for Office 365

By: Vladi Gubler | Comments [0] | Category: General | 10/20/2017


The new Modern UI for Office 365 bring a new, modern user interface to SharePoint Online. Until now, Ultimate Forms required you to view your sites in Classic UI mode as the Modern UI did not support the customization to the extent required by the app.

As Microsoft starts to release customization support, we are now able to offer select features of Ultimate Forms for the new UI. We are proud to release our Ultimate Forms Extensions app, in the first preview version, that brings some of our features to the Modern UI.

At this point the following features are supported:

  • New List Search client-side app version to be used on Modern pages. Closely resembling the existing List Search app part, it brings client-side rendering and updated look and feel. Unlike the existing app part version, it no longer runs within the frame and is able to adjust its size to its content, providing a seamless experience.
  • Custom field rendering in list views - our special field types are now able to render in the Modern list views. Such columns as Color Choice or Associated Items column (and the rest) are able to display correctly both in Classic and Modern modes. There is no additional configuration required, once the app is installed, the columns will just work. Note that you might need to re-save column settings if they were created more than a couple of months ago to ensure they properly register their Modern UI support.

Upcoming features:

  • Event Calendar - will be released by the end of the year.
  • Charts - will be released by the end of the year.
  • Filters - new web part, will be released at a later date, as Microsoft releases support for client-side web part connections.
  • Tabs and column permissions - will be released at a later date as form customizations become available.
  • Custom field rendering in forms - will be released at a later date as Microsoft releases support for form customizations.

You can download the app here. It requires the regular Ultimate Forms app to be installed. Your administrator should upload the app to your App Catalog, you can choose to either deploy it automatically throughout your tenant (recommended) or add the app to each site individually.

Note: this is a preview version of the app, it is intended for testing and demonstration purposes only. Your tenant needs to allow preview features in SharePoint Administration. When you enable this support, it might take up to 24 hours to update.


Ultimate Forms for O365 limits and throttling

By: Vladi Gubler | Comments [0] | Category: Products | 10/16/2017


Infowise Ultimate Forms exists in two version. One is for our on-premises customers and one for customers using Office 365. The products provides you with a wealth of functionality to help you implement your business solutions in SharePoint. Some background features, such as Actions, Item ID or Import, allow you to create and update multiple list items and documents behind the scenes based on list updates or timer.

We allow you to define your own actions and import profiles and specify the logic of which items to update and how many updates to execute each time. The O365 version runs on the Azure infrastructure and uses power Azure App Services capabilities to execute the necessary heavy lifting of querying, evaluating and updating your items.

Unlike the on-premises version that runs on your own servers, Office 365 version runs on a shared infrastructure with essentially limited resources. To ensure smooth and problem-free operation, the app service must always have enough available resources to keep handling incoming requests. 

For that reason, we need to make sure that no single customer utilizes server resources in excess of a certain pre-defined limit. For example, configuring an action that updates thousands of items every single time it executes will take up a significant portion of the available resources, causing a slowdown for other customers. Moreover, excessive use of the SharePoint API could cause the customer to become temporarily blocked by Microsoft as well.

Until now we did not impose specific limits on the resources a customer could use. The app world is still pretty new and we needed time to evaluate if and how the app should be throttled. Lately, we've been noticing quite a few long-running operations that took a significant toll on our infrastructure. Some of these could be unintentional, due to lack of understanding or simply overlooking the implications.

For this reason, effective immediately we begin to impose limits on duration of execution we allow. The first step is limiting the amount of time an action can execute. The actual limit will depend on several factors, such as the scope of your license, but in general, no action will be allowed to run for longer than 500 seconds (this limit will be adjusted as we examine the impact). If several actions are set to respond to a single event, the duration will be calculated from the moment the first action started to execute.

If an action exceeds the limit, we will trigger an execution error within the action. If your action is set to write to the Action History, you will see an error message similar to 'Exceeded maximum allowed execution time'. If the action updates multiple items, some items will not be updated. Items already updated, will not be rolled back.

Similar limits will eventually be imposed for Item ID, Alerts, Imports and other background processes. We encourage you to monitor your business logic execution and make the necessary adjustments to make sure your actions do not get throttled. For example, you can use conditions to limit the number of list items an actions executes on and that way shorten its execution time.

UPDATE 2017-11-06: We are working on a system where the throttling limit will depend on the customer's license type. In general, the higher the scope of the license and the more users it includes, the higher will be the throttling limit (while still remaining under 500 seconds). In the initial version we currently have deployed, the free license for up to 19 users receives a throttling limit of 45 seconds only and the license for up to 100 users receives a limit of 90 seconds. There is currently no additional ranges, but these will be added in the future.


Working with Dates in Ultimate Forms

By: Will Cooper | Comments [0] | Category: General | 10/14/2017

It is easy to get tripped up with dates in SharePoint. Dates are troublesome with any software. There are considerations and exceptions when handling leap years, varying number of days in each month and time zone differences. Date headaches are a given, but there are some approaches that will make life easier.

Add your own auto-updating "Current Date" field to a list

Invariably, you need a way to reference the current date in your SharePoint tools.

SharePoint doesn't provide the reference of "Today's Date" in calculated fields.

Using Infowise, you can do it yourself:

  1. Create a "Date and Time" field named "Current Date".
    1. Set the format as "Date Only".
    2. Set the default value as "Today's date".
  2. Create an Infowise Action with these settings:
    1. General Settings:
      1. Name: "Update Current Date"
      2. Run on events: "Timer-Based", Daily, Hour 12 AM.
    2. Advanced Settings: (Default)
    3. Action Settings:
      1. Values to set: "Current Date" = [Today]
      2. Items: ID = [ID]
    4. Conditions:
      1. ID always not equals 0. (Timer actions require at least one condition.)

Now your list can always reference the current date which will automatically change to the current date each day at midnight. You dashboards will be dynamic and your users will see that KPI Indicator Field automatically change to a Red Flag when the project is late.

Use calculated fields first

Whenever trying to do anything with dates, use calculated fields first. Think of calculated fields as variables that you can add to your list. You won't show these in your forms or list views. These are workers calculating date references for other user facing fields such as progress bars or KPI Flags on your dashboards.

If you haven't practiced with date calculations before, start practicing now! Try creating lots of practice calculations to get a better understanding. Think of this as SharePoint Dates 101. This is must have fundamental learning to have success working with dates. Try to work through these Date and time formulas examples:

Break it into pieces

Calculated fields can reference other calculated fields. Rather than try to build a nasty piece of nested code that handles a long and complicated date calculation, break up the work into multiple calculated fields. Try writing your calculated field formulas in a text editor so that you can check your code carefully. Simply copy and paste your formulas to SharePoint.

Using Infowise Date Functions

Here's a handy list of all the functions available for date calculations in Infowise:

  • Year number from a date: $Year()
  • Month number from a date: $Month()
  • Day number from a date: $Day()
  • Day number of the week from a date: $Weekday()
  • Week number in the year from a date: $WeekNumber()
  • Hour number from a date: $Hour()
  • Minute number from a date: $Minute()
  • Date Time value of today's date at midnight: $Today()
  • Add value to date (Choose Years, Months, Days, Hour, Minutes or Seconds): $AddDate()
  • Convert a date related string to a date value (to assign to a date field): $ToDate()
  • Get the difference in days between dates: $Days()
  • Get the difference in hours between dates: $Hours()
  • Get the difference in minutes between dates: $Minutes()
  • Get the difference in seconds between dates: $Seconds()

Create a Reference List

Here's a novel approach. Add a list to your site to create date references for handy reference in your other SharePoint lists. You can do all the hard work in this list and create your own "date functions" that SharePoint does not provide! Here is a way to get First date of the current month, Last date of the current month, first date of the previous month and last date of the previous month.

  1. Create a simple SharePoint custom list and add one field "RefDate" to store date values. (Format set to Date Only.)
  2. Create four records titled "FirstDateThisMonth", "LastDateThisMonth", "FirstDateLastMonth" and "LastDateLastMonth".

  1. Now we can add some Infowise Actions to automatically update these values: 
    1. For each action, create a Timer-based action that executes once a month on the first day of each month.
    2. Set the RefDate value for each action:
      1. First Date of this month: $ToDate($Month([Today])-1-$Year([Today]))
      2. Last Date of this month: $ToDate(($Month([Today])+1)-1-$Year([Today]))-1
  • First Date of last month: $ToDate(($Month([Today])-1)-1-$Year([Today]))
  1. Last Date of last month: $ToDate($Month([Today])-1-$Year([Today]))-1

Here is the pay off! Now that we can treat these references as functions in other lists.

For example, if you want to run a monthly report, you can make a reference from an action like this:


This function assumes that the Date-Reference list is in the current site. It selects the record by title and pulls back the date. You can use these references from all over SharePoint to consistently pull back these date values any time it is needed!

With the combined power of Calculated Fields and Infowise Functions there is no limit to what you can calculated for your Date Time fields. Setting up a Date Reference List allows you to create your own Date Time Functions allowing you to do the hard work only once and reference these values from throughout your SharePoint environment.

Do you have a cool approach that you have figured out? Do you have a nasty problem that you can't solve? Post a message and let us know!


New Hourly Actions Available

By: Vladi Gubler | Comments [0] | Category: Products | 9/28/2017

Actions are a great way to implement your sophisticated business logic without the complexity of workflows. Using Actions, you can perform changes both inside your SharePoint and in external system, such as Active Directory or line-of-business applications. Actions are easy to confgure, even for non-technical users, they do not require deployment and are ready to run as soon as you click Save. And with 15 different action types, there is nothing you can't do!

Actions can be executed in a variety of way. They can respond to list events (such as items being created, modified or deleted), they can run on a timer or they can even be executed manually by a user. Let's focus on the timer-based actions. Here we have two choices, either execute based on a date column (such as run an action two days before the Due Date, with the ability to repeat) or run on a daily, weekly or monthly basis at a specific time and day (where applicable). Our newest addition is the ability to run an action every hour, for your fast-changing applications.

I'd like to focus again on hourly/daily/weekly/monthly actions. We've covered this topic before in documentation and tutorials, but there is still some confusion. Every action needs an item to run on (what we call the "current item"), it doesn't necessarily mean that the action is supposed to change this particular item (in fact is could be working with an external line-of-business application), but the column values of this item will serve as input data for the actions and the action execution result will be written into the action history of this item. Without a current item to run on an action cannot execute. In most cases, with event-driven, manual or timer-based action involving a date column, the current item is selected implicitly. It's the item that was clicked on, modified or added or one with the date value matching the action settings (say, it expires in two days and that's when the action is configured to run).

But when an action is set to run hourly/daily/etc., it is simply executed during that time and does not have a current item to run on. Didn't I just say that every action requires a current item? There is no contradiction, these timer-based action do receive a current item, but in a special way. Such actions require one of more "static" conditions. What makes a condition static? Any action can accept conditions, they ensure that the action only runs when needed. For example, Status equals Completed makes sure the action only runs on completed items. In the condition settings you select a column on the left, an operator and a value on the right. For instance, "Status" was our column, "equals" was our operator and "Completed" - our value. (For more advanced users, yes, I'm omitting "always"/"after change" setting for simplicity). Now the value part is what's important now. Here you can set static values, such as Completed here, but you can also reference column values from the item, such as Due Date greater than [End Date], in this condition we compare column values of Due Date and End Date.

Hourly/daily/etc. actions require at least one static condition. When the action is triggered, it first executes the static conditions to query the list. Such as Status equals Completed will return all items with Status Completed. Now it will go over item by item and execute itself on it, passing that item as the current item. It will then execute the conditions again, this time all of them, not just static ones and continue as usual. This initial selection of items to run on requires static conditions and you won't be able to save your action without them.

Please make sure to configure your conditions careful and as narrowly as possible, you don't want to waste your server resources going over thousand of items each time the action runs.

Hourly actions are already available in the app version and will be added to the on-premises version soon.