Creating Your First Solution with skybow: What to Keep in Mind

It occurs to me that, when people first use Solution Studio, it takes a short while to figure out a few things. Once you have, Solution Studio becomes extremely easy, and genuinely fun. But a lot of SharePoint people used other tools that had assumptions of their own, and so their are biased.

‍

Shall I save you a day or two, and make your first attempt at building a skybow Solution even nicer? It’s a little longer than my normal blog post, but it’s worth it.

The solutions.skybow.com portal contains only a list of your projects. The projects themselves live in your sites.

When you decide to build a solution in a particular site, skybow adds a hidden library to it. We add an IDE made entirely out of HTML and JavaScript into that library, and that’s what you’re using as you create your solution.

‍

‍

When you login to solutions.skybow.com you’re just logging into a website with a list of your solutions, or projects. When you click on a solution, you’re taken to the site where your project lives. You may then need to logon to that SharePoint site.

‍

‍

Start with the data tier.

A skybow solution starts with data, then adds forms, and then you add custom logic. You begin by – inside of Solution Studio – building the lists and libraries that will be used in your solution. You don’t have to build them in advance within SharePoint (if you did, don’t worry; you can add them to the solution afterwards).

‍

There are two sets of lists/libraries, Dossiers and Other Lists/Libraries. You should focus on the former for the most part.

A dossier is what skybow calls a set of lists that work together. Conceptually, it’s a master/detail relationship being done, although there can be multiple detail lists/libraries involved. Behind the scenes, it a group of lists/libraries in which one of them is being referenced by lookup columns in all of the others.

‍

If you create a dossier in Solution Studio, you first create the master (or parent) list (or library). Once you’re done, you create sublists. Solution Studio will create all the lookup columns for you – you don’t need to do that yourself.

‍

‍

There are three big reasons to use dossiers.

First off, when you finish creating a dossier, Solution Studio will create a unified set of forms and actions that are aware of the relationships between the dossier’s lists/libraries. It will show up as a form for the master list with tabbed pages representing all of the detail lists/libraries. It will also add action links to the Quick Launch area to add new items to the detail lists.

‍

Secondly, Solution Studio, knowing about the relationships between the lists, can perform background calculations on them. You can have a column in the master list contain totals of all the items in a detail list, for example. In an expense report, it allows the total to be auto-calculated without having to put all of the work in the form.

‍

Thirdly, since you can only query one list at a time (no joins allowed), it might be useful to copy some of the columns in the parent list down into the detail lists just for searchability/browseability. We call that metadata inheritance. It’s also an automatic background function.

‍

Create calculated columns as soon as you need them, but don’t add summary formulas or metadata inheritance details until the dossier has been generated.

Solution Studio creates those lookup columns automatically, but not until you click the New Dossier wizard’s final “Finish” button. Once the dossier exists, you can go back to “Things in Background” for a list to add Summary and Metadata Inheritance formulae.

‍

There’s an assumption that users focus on a master list item, specifically its Display form, and that the New and Edit forms are temporary popups.

A skybow solution is a SharePoint solution, and SharePoint lists have three forms associated with them: a Display form for reading an item, a New form for adding a new item, and an Edit form for making changes to an item. Other software has you create one form and tweak its “edit mode” vs “display mode”, but that’s not how SharePoint really works.

‍

‍

The expectation is that users will click on an Action Link to add a new master list item and click Save; they’ll be taken back to the list view, and there they can open their new item to display it. They can click on an Action Link to edit the master list fields, or on another Action Link to add detail items. But all changes are done with popups.

‍

‍

This is necessary on a New item form, since the item’s ID won’t exist until you click Save; the detail list items need it to already exist. So New and Edit can’t be done at the same time.

‍

Get the Display form the way you want it first.

Once you have the Display Form laid out the way you want it, you can add export it’s layout to a file and import that into the New and Edit forms. After doing so, be sure to remove extra details, tabs, action links that would make no sense on the Edit and New forms. Remember, the assumption is that New and Edit are popups over the Display form.

‍

You don’t have to do it this way, but you’ll need to edit a lot of settings if you want something different.

If you want to create the effect of having a single form with View/Edit modes, it’s still going to be three forms, but you can make them look the same. You’ll need to make some adjustments, though:

‍

In the Display form:

• In the Edit action link, change the Open In setting from Modal Dialog to Parent Frame.
• Remove the Refresh action from the Edit action link.

In the Edit form:

• Remove the toolbar and replace it with individual Save and Cancel buttons. Edit their actions to redirect to the Display form after saving/cancelling.

In the New form:

• Either remove the detail list tabs or make their contents read-only. Ditto any action links.

‍

My life got easier when I just decided to accept the notion of the Display Form being the main thing. If you can, you can have applications built in minutes instead of needing an extra hour to modify their behavior.

‍

You can embed implicit process logic in Action Links.

Every action link can be shown/hidden/disabled/enabled based on rules. Those rules can be a combination of (a) a field in the item you use to show Status and (b) the identity or group membership of the current user.

‍

‍

So you could add a “Request Approval” Action Link that is only shown if a column you create named “Status” shows a value of “Unsubmitted”. You could have two links named Approve and Reject that are only visible if Status is “Submitted” and the current user belongs to a specific group (or is the list item creator’s manager, etc.).

‍

You could also wire up the form to a Microsoft Flow, but that won’t be easy to package and deploy. Remember…

‍

You’re building a solution that you’re going to deploy somewhere else. This is a Very Good Thing.

Most low-code/no-code tools assume you’re working in a production site, and when you get your app to the point where you like it, people just start using it. If you continue to make changes, people will just have to adapt on the fly, and you’ll need to be careful that those changes don’t break anything.

‍

Solution Studio is all about building in a dev site, then deploying it to another location for production (or testing). During deployment, all list/column IDs are recalculated – it just works.

‍

But if you add external things to your solution (like a Microsoft Flow, for example), it will have an impact on being able to deploy the whole thing with one click.

‍

Think of Packages as releases.

Packages have version numbers. If you create a new package, you can update existing deployments to the new package version really easily. If you need to revert to an older package, that’s not especially hard, either. You can also create a package as a special release with a few one-off modifications for one deployment. Packages are good.

‍

‍

Name packages the way you’d name releases. For example, “Initial Release”, “June Update”, “New Support for Activity Logging”, etc.

‍

Name deployments based on where they’re being deployed. For example, “Seattle Timesheets”, “Zurich Timesheets” would be two different deployments of the Timesheets solution, and both are using the June Update package.

‍

Don’t forget to add Navigation Links and Lookup List values.

Packages aren’t just about lists, libraries, forms, and action links. The site’s theme, its logo, its style sheet info, and navigation links can be added to the package. You can, for a list you’re using to store lookup values, elect to include the data in that list in your deployment, too – so users don’t need to populate that table before using your solution. You can also include a set of graphic images you want to reference in your forms (either in image controls or action links). You can even include custom web part pages to add to the page library.

‍

A solution can either be added to the site or can take over the site entirely.

Solution Studio’s path of least resistance is to add your solution to an existing site. To make it take up the entire site, you’ll need to override the site’s home page, possibly adding other pages as well. Solution Studio makes that easy, but it doesn’t automatically do it by default.

‍

Moreover, you can opt to create a new site both when deploying a package or creating a new solution in a development site.

‍

That’s it – have at it!

None of this should be daunting. I didn’t find it so. In fact, once I understood it, it was painless and straightforward. It’s, more or less, the way professional developers code custom site pages, forms, actions, etc.

‍

Low-code/no-code people tend to think of forms as separate things (and in PowerApps and other tools, they are), but in SharePoint, they’re just pages with web parts and scripting. Solutions built with skybow tools are meant to embrace SharePoint’s design rather than disguise it.

‍

It’s a good thing. Go have fun with it.

‍