10/16/2017 by Vladi Gubler
9/28/2017 by Vladi Gubler
5/18/2017 by Vladi Gubler
3/20/2017 by Vladi Gubler
3/16/2017 by Vladi Gubler
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.
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.
We got requests from customers to make validation errors on forms more prominent. Up until now, if you had a validation error on a tab, we would add a red asterisk to the tab name. Customers felt that it was too easy to overlook, especially with larger forms. The Save button would then not work and it would take time to figure out what was going on.
We added a more prominent error sign to the tab name and also a validation summary box under form, listing tab and column names with validation errors, like so:
Hope it helps make forms more user-friendly, just re-save the tab settings to get the latest version.
The change applies to O365 customers only, on-prem customer already received a similar update in one of the latest versions.
New feature in Ultimate Forms: you can now configure where the Edit form redirects when you click on Save. By default, the form redirects back to the list view. Now, you are able to configure the target of redirection to the view (default), edit form or display form. Additionally, you can configure whether to add a new button to the form (Save & Edit or Save & View) or just to use the regular Save button. When you use the regular button and redirect back to Edit form, the second time you save, you will be redirected to the view, to prevent users from getting stuck in an infinite loop.
One of the common reasons to use this feature is integration of actions. Actions are executed on Save, so the user might need to perform additional data entry based on the results of the action execution. Note that in this scenario it's best to set the action to execute Synchronously, to make sure it completes before the form reloads.
The new features is accessible under General Settings section of Tabs and tab permissions.
NOTE: the feature is already added to the app version and will be coming to on-premises version in the next release.
In multi-lingual sites, the user interface of the site will appear in the preferred language of the current user. The same site will be displayed in English, French or Spanish, based on who accesses the site. You can even localize the column names, to make the forms appear in the preferred language.
When you add tabs and tab descriptions, they will appear in the language in which they were created. So if the site creator uses English, the tab names will appear in English even when the current user sees the site in French.
We now added a new feature to Ultimate Forms that allows you to translate the tab names and descriptions into additional languages. They will then appear to user translated into the preferred language (provided of course that you included the relevant translation).
Note that section names and fragments cannot be currently translated.
NOTE: the feature currently applies to the app version only. There is an existing translation mechanism in the on-premises version, the new app mechanism will be migrated to the on-prem version in the future.