Category: Office 365

Mike’s 2019 Predictions

With 2018 over and 2019 just beginning I thought it would be fun to make a few guesses as to what I think will happen around the technologies that I work with on a daily basis.

Predictions

SharePoint Online Intranet projects move from boxed solutions back to OOTB then back to boxed
SPFX will play a larger role in a SharePoint Developers toolbox.
Serverless architectures will move from trial, curiosity and POCs to mainstream first class architectures

Intranet Projects

Currently there are a variety of different boxed solutions for corporate intranets. Examples would be GO, Bonzai, and Sparrow. These are all great solutions to get your intranet done quicker and lower the development time to create an engaging intranet.

The downside is that you are tied to a specific vendor. Locked in for a support contract with no real options to move if you are unhappy with them for what ever reason. These intranets are based off of classic publishing sites templates. While not necessarily bad, Microsoft is just not investing in this space anymore.

Microsoft has rearchitected the way SharePoint sites work. With the release of Hub, Modern Team and Communication sites and with the most recent updates to these site templates. I feel most organizations can finally start to build OOTB Intranets that look custom, look on brand, and are relevant to the users consuming the content.

While the makers of Go, Bonzai, Sparrow and others figure out their best path forward on how to create useful products in this new world. Organizations will start to leverage these new updates in their intranets as first step instead of as an addon.

SPFX — SharePoint Framework

The SharePoint Framework is a client-side development toolkit that allows you to build Webparts and extenstions for SharePoint Online, SharePoint 2016 with FP2 and SharePoint 2019 and most recently Teams.

The ability to write a solution once and have it work in any modern SharePoint environment and Teams is huge win for developers and the money counters. SPFX being entirely TS or JS based fits quite nicely into organizations DevOps strategies.

SPFX is the best way to write web parts for modern SharePoint sites.

Serverless Architectures

As SharePoint developers adopt SPFX as their main way to create web parts for SharePoint and teams. Some functionality will be lost. The ability to run server side code. This is where I think serverless architectures will start to take off more.

Since SPFX is entirely client side facing developers will need a solution to deploy and client side code that they may need. The answer for this in the Azure world will be Functions and Logic Apps. In the amazon world it will be Lambda.

The idea being that instead of creating an entire infrastructure to host what is most likely a small piece of logic. We have these serverless architectures where our logic is hosted and called only when it is needed. Saves a lot of time and money.

How to do Workflows in SharePoint: Part 2 – Parallel Actions

Post author By Andrew Chomik
Post date December 13, 2018
2 Comments on How to do Workflows in SharePoint: Part 2 – Parallel Actions

This is part 2 in a blog series of basic workflow design using SharePoint Designer and Microsoft Flow. See How to do Workflows in SharePoint: Part 1 – Conditional Starts for the first entry in this series.

Sometimes you want a workflow to do more than one thing at the same time. It is not an uncommon business case to require simultaneous activities, especially if the workflow needs to do different things with different groups of people (e.g. getting separate streams of approvals between Supply Chain and HR).

SharePoint Designer (SPD) and Microsoft Flow will always conduct workflow steps in sequence. If you require that certain things get done simultaneously, both applications can provide the controls to do it.

SharePoint Designer

Use a SharePoint 2013 workflow on the library or list. Parallel blocks are not available for SharePoint 2010 workflows.

Insert a Parallel Block (inside a Stage). You can do this from the Insert section of the Ribbon (or by right-clicking).
Write the logic you need in each block (there is a slight indent into the parallel actions).
That’s it! Consider using Steps inside Parallel Blocks to organize your parallel actions into manageable blocks (and to see your actions visually separated from one another!)

Nested Parallel Blocks (Waiting for one of multiple things to happen)

Parallel Blocks can also be used for Conditional Starts in waiting for a field to change in order to proceed a workflow. This is handy if you want to wait for certain values in a field before doing the next step (e.g. approval statuses).

Add a Parallel Block to your workflow.
Add as many nested Parallel Blocks inside the parent Parallel Block as you need.
For the parent Parallel Block, right-click on it and click Advanced Properties.
Set the “CompletionCondition” to a new boolean variable. By default, the new variable will continue further if the variable equals “true”.
In each nested Parallel Block, add a “Set Variable” status so that the new variable equals true.
That’s it!

What you will get is the workflow “waiting” for one of the nested Parallel Blocks to be true before proceeding. This is very handy if only certain conditions have to be met, and not working within the limitations of the operators provided (e.g. equals, not equals).

Microsoft Flow

On a workflow that already has a trigger and an action, hover your mouse about the connector line and click the + button. You can add a parallel branch. When the new parallel branch is created, it will be create adjacent to the main workflow stream. Add all of the actions you need within this branch. When you want the parallel actions to end, just at a new step at the after both branches are complete (it will auto-join).

On a workflow that already has a trigger and an action, hover your mouse about the connector line and click the + button. You can add a parallel branch (1).
When the new parallel branch is created, it will be create the new branch adjacent to the first workflow stream. Add all of the actions you need within this branch in sequence as required (2).
When you want the parallel actions to end, just add a New Step. It will conjoin the two (or multiple parallel blocks) together (3). This is not the same thing as “adding a step” under a current Parallel branch; two different function!

Which one is easier? Microsoft Flow, for the simple fact that it is visually easier to look at when doing branch design (this just doesn’t look as appealing in text-based logic, but to each their own). Of course with that said, you can always view and edit your workflow in Visio (click the View button and pick “Visual Designer”).

In the next entry in this series, we look at basic steps to scheduling workflows (a bit more advanced, depending on which tool you are using!).

Please visit my blog Ion All the Things for helpful information about SharePoint and Office 365.

Office 365 SharePoint Workflows

How to do Workflows in SharePoint: Part 1 – Conditional Starts

Post author By Andrew Chomik
Post date December 10, 2018
1 Comment on How to do Workflows in SharePoint: Part 1 – Conditional Starts

Workflows are the lifeblood of organizations. Business processes – and their efficacy – are critical to the successful operation of a team, business or organization. This is why the workflows you use in your collaboration tools should be easy to build, deploy, and use by people of various responsibilities and technical chops. SharePoint workflows should follow suit.

In the first of this three-part series, I will address some common scenarios you may need build into your SharePoint workflow and how to go about building what you need in both SharePoint Designer (still kickin’) and Microsoft Flow (the shiny new object and getting shinier!) Below are simple ways to begin your workflows that need have conditional starts, where certain conditions must be met on a document or item before the workflow can proceed.

SharePoint Designer

Create a new SharePoint 2013 workflow on your library or list.
Set how the workflow starts (created, modified, manually) in the options menu.
In the Logic screen, insert an “If” statement in the first stage. Add another “If” statement right below it to create multiple conditions (something not so obvious in SPD unfortunately). This is where you can select your operator (“and” or “or”).
Pick the fields and pick the values it must meet conditionally.
Complete the If/Then logic you require. Don’t forget to use an “Else” statement to tell SharePoint what to do if the “If” statement isn’t realized, otherwise it will continue to follow through in chronological order. It is also good practice to include a “Log a Message to the Workflow History List” so that any audits done on the workflow for a given list item can be reviewed with more context and see how the workflow followed the logic.

A basic workflows in SharePoint Designer with a conditional start.

Microsoft Flow

Start a new workflow (either from a template or from scratch).
Create a Trigger. Your trigger should be how you want the workflow to begin (on item or document creation, modified, manually, for a selected item, etc.)
Create a Condition action (use Basic mode for one condition, and Advanced Mode or parallel or nested conditions for more conditions).
Add your subsequent workflow steps in sequence.

A basic workflow in Microsoft Flow with conditional start.

Which one is easier? I feelSharePoint Designer is easier on the whole, especially for starts that require multiple conditions (you don’t have to write logic in Advanced Mode or do nested conditions). However, the graphical user interface may be more appealing to some workflow builders. Try both and see what you like!

Next in the series is how to handle Parallel Actions (having more than one action run simultaneously).

Please visit my blog Ion All the Things for helpful information about SharePoint and Office 365!

Tags Office 365, SharePoint, Workflows

Office 365 Uncategorized

Form Accompli: The rest of the Best for Using Forms in SharePoint (Part 3)

Post author By Andrew Chomik
Post date March 9, 2018
No Comments on Form Accompli: The rest of the Best for Using Forms in SharePoint (Part 3)

If you didn’t hear enough about forms in SharePoint from my first two blogs, then I promise this is just a trilogy and you’re on Return of the Jedi. We’re close to the finish line.

In my final part of this series on how to use Forms with SharePoint, I focus on the “rest of the best”; the remaining Form solutions that your organization can use in order to meet (or even exceed) your form requirements. And whether you are looking to enhance your current forms or roll out an entire set for a shiny new SharePoint environment, there is something for everyone that doesn’t include Forms or PowerApps.

In case you don’t feel like reading the rest of this, here is a handy TL;DR (too long, didn’t read) table. If you ask me to pick only one forms solution for SharePoint, I’m vouching for PowerApps. It’s the best option going forward that takes the best advantage of the Office 365 stack and subscription.

Now, the rest of the Best . . .

Microsoft InfoPath 2013

Ah, the incredulously resilient forms product that seems to have the half-life of Bismuth-209. This thing just won’t go down, as much as your Info Services team wants to see it vanish.

The problem with InfoPath is that it is still useful and still an effective way to edit forms in SharePoint. And it can’t go away quite yet; there is still some blood to be squeezed from this stone, and a surprisingly good amount.

InfoPath has been the gold standard of form editing capabilities in SharePoint for years. I say this because if you already have SharePoint environments (on-premise or in the cloud) and forms have been edited by at least someone for, say complex workflows, chances are InfoPath was the tool used for the job.

InfoPath provides the following benefits for integration with SharePoint:

No code – a major difference maker for users who don’t need complicated IT projects to get better forms (although there is a bit of a learning curve);
Adding expanded user inputs to customized workflows in SharePoint (e.g. organization-specific metadata for content approvals, or user-initiated content management);
Creating enhanced create/edit forms for SharePoint lists and libraries, improving the user experience and ensuring the right metadata is captured;
Custom branding to further extend your intranet, extranet, team site, or website look and feel;
There are many tutorials and guides online with good knowledge bases to use and learn from. I suggest taking a look at the Microsoft Infopath Tutorial and Online Training Course from LearnThat, downloading the Advanced InfoPath Form documentation from Microsoft TechCenter, or even taking the InfoPath 2013 Essentials Training by Gina von Courter (if you have access to LinkedIn Learning).

It’s a Microsoft product, and it’s free. And more importantly, it provides a level of form editing capabilities that is effective – which at the core, is what most people want (it “gets the job done”).

Microsoft is not dropping support of InfoPath until 2026, so that gives you quite a bit of time before you have to take the plunge with another solution. That means the forms you built for use in SharePoint 2010 and 2013 can still be put to good use. Heck, Microsoft folks have even confirmed it will be compatible with the upcoming release of SharePoint 2019(huzzah!)

While these are good reasons why there is no immediate rush, others may advise to not use InfoPath any further, simply because it’s becoming “abandonware” and you should ween yourself off of it. But I will play devil’s advocate and tell you to continue using InfoPath under the following conditions:

Your organization or team is currently deriving value out of forms already built in InfoPath and used in production and are not in an immediate need to change over (especially if your tech support teams are able to service the forms). There is already a level of familiarity and expertise inside the organization with it.
You do not have any further forms to build that are complicated in nature, and need to be woven into extensive SharePoint workflows and content publishing.
Microsoft Forms or PowerApps are not capable of delivering the forms you currently have, or you do not have resources able to make the conversion (e.g. budget, time, skillsets to do it, etc.)
You understand that InfoPath is effectively abandonware, and Microsoft will not be giving InfoPath any further updates or extensive support for your existing forms. You are on your own path until InfoPath is fully gone eight years from now.

InfoPath is a legitimate option and should not be discarded so easily. However, if you are keen to make the switch to Microsoft PowerApp and Flow, there is a definitive successor that awaits your future form experience, and it’s a leap you will eventually have to take – even if that leap doesn’t have to technically be made for almost a decade.

Nintex Forms

Nintex Forms for SharePoint offers a no-code, drag-and-drop forms experience for users to build and deploy forms to SharePoint lists and sites. It works with on-premise SharePoint environments and Office 365, and is an industry pillar in the SharePoint third-party market. Some of the notable advantages of the Nintex experience include:

High customization on forms with ability to control function, branding, and content source integration (e.g. SharePoint, SQL databases, etc.);
Easy to ramp-up on usage with an intuitive GUI; relatively low learning curve compared to InfoPath;
Anonymous or Authenticated form submissions;
Mobile and Tablet-friendly for phones and tablets (both using forms and creating/editing them);
Embed forms with Nintex workflows (this is really the strength of the product).

You don’t have to go far to find excellent review of their product set. They have a strong, reputable product that I have seen in multiple client locations (from just testing purposes all the way to full-blown deployment). Additionally, Nintex is partnered with a number of other SharePoint products and services, including Portal-in-a-Box solutions like Bonzai Intranetand migration specialists like ShareGate. If you’ve invested in one of these, that gives it a leg up (for a full list, you can see all partners listed on Nintex’s website). They have also been around since 2006; their products were the first-to-arrive combination of Forms and Workflows that weren’t out-of-the-box, and before the PowerApps/Flow combination appeared on the scene in very recent history. Bascially Nintex is the grand-daddy of third-party integration into SharePoint to do better than what SharePoint offers on its own (in this consultant’s own opinion).

There are other major third-party players in the SharePoint forms game, including K2 and Formotus. However, full product reviews can be found elsewhere on the net; Nintex is in large enough circulation (at least in the Canadian and North American market) to warrant itself as it’s own option.

One major prohibiting factor for Nintex is that it is a pricey option, especially for small to medium businesses that will not be using copious amounts of forms or workflows (the latest check has Nintex subscription pricing starting at $625/month for five workflows and 25 forms). This also doesn’t include potential up-sell from consulting services and general long-term expanded usage of the product. Note that Nintex Forms itself does not have its own pricing scheme; there is likely little way around getting the workflow components as part of your package (even if you don’t need them).

Additionally, I have yet to see Nintex deployed in small to medium businesses; these organizations (often with limited budgets) will likely find better value in InfoPath, Forms, or PowerApps/Flow, especially as they are already available in standard business usage of Office 365.

At this stage of the game, I would probably be recommending customers to give the PowerApps/Microsoft Flow combination a try before going to Nintex. The reason for this is that, all things being equal, you’re better off sticking with the Office 365 stack and being able to move content around and conduct information management activities with the same vendor that built the product. Additionally, PowerApps and Flow are very robust and accomplish alot of the same technical objectives that Nintex Forms does – and without having to coordinate two different vendors, and paying more than you already do Office 365 business or enterprise licenses.

The bottom line for Nintex is this: it is a robust, capable and well supported form solution, and it’s powerful. It’s a very good option. But it is an investment. And this isn’t a decision you can just jump in to; you’ll have to consider your current form usage and your larger use of workflows to get the full value of it – and you should consider whether you have custom forms already, and what a transition strategy will look like.

Anything else?

There are few other ways you could edit forms in SharePoint. You can try the many different Form apps offered in the SharePoint Store – KwizCom, PlumSail, Sidekick365 offer forms apps that you can install (but may have to deploy additional code on SharePoint servers). Even the trial version of Nintex Forms are found here from an installation starting point).

Even though these are freely available, I would not recommend any of these, unless your organization can comb through the product, the product code, and conduct relentless sandboxing and testing activities around form usage before actually deploying into a production environment. This includes reviewing the efficacy of the product, the granular controls and functionality, the graphical user interface, business-appropriate scenario testing, and even the troubleshooting components that can make or break a user experience (e.g. form and workflow debugging). questionnaires

Your data is too important and sensitive to compromise with a free SharePoint Store app that might not be built with the level of security and stability you need. Forms (and the content and workflows around them) should never be implemented in a half-baked manner. Put the time in to explore any of these options – KwizCom, PlumSail, Sidekick365, and anything else.

Of course the final option is using Visual Studio. This is the full custom, full development route that should only be used as a last resort. Office 365 is designed to handle most of the business activities that regular, non-developer users will ever encounter (and allow you now to create your own solutions even for what it doesn’t).

Going down the custom form development route only adds a level of complexity to your SharePoint environment that will cause extra leg work when trying to do any sort of platform upgrades, migrations, or tool integration. This route should only be used for the most complex of requirements, including integration with other business systems (e.g. CRM, ERP) and/or where user inputs are required on stand-alone SQL environments that the Office 365 can’t immediately handle.

With that said, I will close my soliloquy on forms in SharePoint. I am sure I’ll have to re-visit this series of blog posts in two to three years, when all of this will change when something in the industry bulldozes everything again. In this industry, you can never bet against it.

Check out the Ion Works blog for other advice around Office 365 and contemporary industry musings. We are a collective bunch of industry guys who like to Office 365 (it’s now a verb), and shed some light on ECM and content/collaboration stuff. We are also moving domains – stay tuned on my LinkedIn and Ion Works Twitter!