Mapping Classic to Modern Web Parts

One of the things we help people with is making the change from the way they used to do things to new ways of doing things. That’s why we created a mapping between classic web parts and modern web parts. The idea is that if you know how you used to do something, you’ll see how to do it today.

Community Support

In a few cases, there aren’t any out-of-the-box analogs to the classic web parts, but there are community contributions. We took the liberty of compiling them and making them available. If you’re looking for a script editor or a modern search web part, we’ve got them available for you. We ask that you complete a free transaction to get the web parts, so we can keep you updated whenever we update the compiled version on the site.

More to Come

As we get more modern web parts that are developed by the community – and new web parts out of the box in SharePoint – we’ll update the table, so you’ve got one place to go for a comprehensive reference for how to do in modern what you did in classic – and whether it’s available or not.

If you think we’re missing any, feel free to drop us a line.

Uploading Document Templates to Content Types on Office 365

We’ve had the ability to upload document templates to content types in SharePoint since SharePoint 2007. It’s been the way organizations that want to manage the forms used by employees would publish them. However, recent changes in Office 365 have broken this capability by default. There are a few workarounds to the problem – but none of them are particularly desirable.

Changes and Scripts

For some time, Office 365 has treated uploading a document template to a content type as “custom script.” In the tenant admin settings page, there’s a section for custom scripts:

We’ve had to tell customers to set this to “Allow” because of the impact it has on blocking document templates. However, a more recent change requires an action for every site collection that’s created.

There’s a new site collection level flag called DenyAddAndCustomizePages. When it’s set, you can’t upload custom documents to content types. If you’re still using the classic SharePoint administration, this flag isn’t set, and you’re fine. However, if you are using the new SharePoint administration, site collections you create get this flag set. To resolve it, you must connect to your tenant and then do a set-sposite <url> -DenyAddAndCustomizePages 0. This releases the flag and allows you to upload the document template. This works as long as you are a tenant administrator or you can get the administrator to run the command for you – but for many people, this will prevent them from being able to do the best practice for managing document templates.


In addition to manually resetting the flag to zero, there are two workarounds. First, use the Content Type Hub (/sites/contenttypehub), which is still created without this flag. This works if you have access to this site collection. You can create and then publish the content type, which will get it into every site. That’s fine if you want to publish a content type to every site – but that may not be ideal for everyone.

The second approach is to fall back to SharePoint classic administration, because it doesn’t set this flag.

Path forward

If you want Microsoft to fix this, can I suggest that you up vote the suggestion at

Is This SharePoint Page Published?

I was listening to my friend Sue Hanley speak on a user adoption panel, and she mentioned a problem. Users can’t easily see whether a page is published or not because of the way that versions work in SharePoint, and I realized there was a simple answer. In the process, I slammed into a defect, and it’s one that hasn’t been resolved. However, if you’re interested in a one-time snapshot of what’s published you can still use this trick. Skip down to the Calculating Published header if you don’t want the backstory.

Major and Minor Versioning

We’ve had major and minor versions in SharePoint since the beginning. Most document libraries have simple, major versioning enabled, which uses integers to differentiate one version from the next. The latest version is the version with the highest number. If you want to know what the users see by default, it will always be the highest numbered version.

Major and minor versioning is enabled for pages libraries, and it uses a floating-point number to represent the version. Everything to the left of the decimal (whole numbers) is the major version and everything to the right are the minor versions. The challenge comes in that users who have read access don’t get the highest numbered version. They get the highest version with no decimals (i.e. the largest version that ends in .0). This causes confusion, because anyone with editor status will see the highest number – including minor versions. So, a user calls and says they can’t see something that the editor or creator can see.

When a content manager publishes a page, it’s converted from a minor version to a major version and they can see it. However, it’s not easy to see whether pages have been published or not. You can display the version, but you must remember that only major versions are seen by users. If only there were a column that let you know whether the page was published or not.

Calculating Published

SharePoint’s support for calculated columns allows us to do simple operations, and we can take advantage of some Boolean logic to create a column named “Is Published” that will tell us if the item is published. We do this with a simple formula:


We’re subtracting the integer portion of the version number from the rest of it, leaving us with only the remainder. If that is equal to 0, then the version is a major version and thus the page is published.

Here are the steps to add the column to your Pages library – and the default view:

  1. Navigate to the Pages (or Site pages) library of your site.

Figure 1: The Site Pages Library

  1. In the upper right-hand corner of the page, click the gear icon to open the Settings pane.
  2. Click Library settings. The library’s Settings page will open.

Figure 2: The Site Pages Settings Page

  1. In the Columns section, click Create column. The Create Column page will open.

Figure 3: The Create Column Page

  1. In the Column name field, give a name to your column, such as Is Published.
  2. For the column type, select Calculated (calculation based on other columns). The page will refresh to show additional options in the Additional Column Settings section.
  3. In the Formula box, type (Version-Int(Version))=0.0.
  4. For the data type returned from the formula, select Yes/No.

Figure 4: The Configured Formula and Selected Data Type

  1. Make sure Add to default view is checked, then at the bottom of the page, click OK. The column will be created, and you’ll be returned to the library’s Settings page.
  2. To return to the library, at the top of the page in the breadcrumb bar, click the name of your pages library. You’ll be returned to the default view, where you will see the new calculated column. (We’ve also included a Version column to indicate that drafts are listed as No and published pages are listed as Yes.)

Figure 5: The New Calculated Column in the Site Pages Library

  1. First, we’ll edit a draft page, but we’ll save it as a draft instead of publishing it. Click the name of the page to open the page in a new tab. In the command bar, click Edit, then make any changes as needed. When you’re finished making changes, in the command bar, click Save as Draft. The page will be saved as a draft, but not published.

Figure 6: The Save As Draft Button

  1. Return to the pages library. The calculated column should read No, because it isn’t published – but it doesn’t. This is the defect. The calculated column isn’t getting updated when the version is changing.

Figure 7: The Calculated Column

Value Today

For now, you can create the field when you need a snapshot. Hopefully, Microsoft will fix the defect soon, and we’ll be able to have a simple column that shows whether a page is published or not. If you want to support Microsoft fixing the issue, upvote the User Voice suggestion at

Using InfoPath Today (Not Just Say “No”)

My friend Mark Rackley sent a note out a few weeks ago asking for a video saying “no” to InfoPath. I politely told him no – to the request. Not because I think InfoPath is an up and coming technology, but because I don’t like what I’ll call “grumpy old men” posts. (His post is Seriously, It’s Time, Just Say “No” to InfoPath.) My hope with this post is to find a more balanced view – and to work on a path forward rather than shaming you into believing that you’re somehow bad because you have InfoPath forms in your environment.

I’ve been trying to help people do the right things with SharePoint (and associated technologies) since 2008. That’s when we released the first SharePoint Shepherd’s Guide. I think that getting off InfoPath is the right path. At the same time, I want people to know the path forward. I want there to be a way to learn how to create forms in new technologies that do the same or similar things that InfoPath does.

Creating vs. Using

The first point of balance is the distinction between creating new forms and having users fill out old forms. These are two different things. Users filling out existing forms is just a matter of converting the form to a newer technology when it’s appropriate. The end of life for InfoPath is set. In 2026, support will end. That still seems like a long way off, and it is. That isn’t to say we shouldn’t start the process of migration from InfoPath, it’s saying that the sky isn’t falling.

Certainly, if you’re creating new forms in InfoPath, you’re creating technical debt. You’re creating more work you’ll need to do in the future. That’s why, if you’re trying to kick an InfoPath habit, the first place to start is with new forms. The second place to go is to update the forms to a new forms technology when you must revise them. I’ll come back to both of these scenarios in a moment, but for now, let’s address the cost of technical debt.

The Cost of Technical Debt

Mark quotes another good friend, Sue Hanley, as saying the cost of technical debt increases over time, so you should start to work on it immediately. As a software developer and in a software development world, this is true. However, the role of InfoPath isn’t exactly that. Certainly, if you continue creating forms, you’re creating greater technical debt. However, if you don’t create or revise existing forms, your technical debt is actually going down – but only slightly.

First, let’s do an analogy. Let’s say that you can borrow money at 4% interest (say on a house), and you can reasonably expect an 8% return on an investment (say in the stock market). In that case, you should really keep as large of a mortgage as possible and invest the money in the stock market. From a sheer numbers point of view, you’re money ahead. Of course, there’s risk and uncertainty, but over the long term, keeping a mortgage and money in the market at the same time is financially profitable – at least slightly. Few people recommend this kind of a strategy even though it’s financially a sound practice.

In the case of InfoPath, the longer you wait – up to a point – the greater number of features you used in InfoPath will be available in other ways, the better the usability of the new tools will become, and the better the education will become. The net effect of this is that your cost to convert – if you’re not adding to your existing forms – will be smaller. That being said, it may not be enough to justify the risk that you’ll run out of time if you wait too long.

There Isn’t a Migration Strategy

There’s not going to be a magic wizard that will convert all your forms into another Microsoft technology. PowerApps, the “heir” to the forms legacy, isn’t built the same way, so there’s no one-to-one mapping between what we did in InfoPath and how it’s done in PowerApps. If you’re planning on staying on Microsoft technology for forms, you’re going to have to do the heavy lifting of converting your forms by hand.

As Mark points out, there are a few third parties that have InfoPath converters already. It’s a big market, and there may be more forms vendors that want a piece of this market. In the worst-case scenario, you might be able to defer the cost of changing your forms until near the end of support, and then use the automated conversion to another technology. The risk here is that the converter technology won’t handle the tricks you used with your complex forms. It’s another possibility for deferring the investment – but it’s not one that I’d recommend unless you’re absolutely backed into a corner.

It’s a Modern World

SharePoint’s modern pages are beautiful and responsive in ways that the classic interface could never be. If you’re delivering your InfoPath forms via the browser and InfoPath Forms Services, you’ll never get the beautiful modern experience, because InfoPath Forms Services isn’t going to get an upgrade to modern. This can be an issue once you’ve made the change to all modern, but if you’re still working with an on-premises server, it’s likely that you’ve not yet made the switch.

The good news is that the forms will continue to work – they’ll just have a classic interface.

Creating New Forms

The real rub for the InfoPath end of life comes for those organizations that are still creating new InfoPath forms because they know how to do it – and they don’t know how to do the same things in PowerApps. In most cases, it’s time to bite the bullet and learn how to accomplish the same objective in PowerApps rather than creating more technical debt with an InfoPath form.

Even if you’re just modifying an InfoPath form, it’s time to consider your other options. It may be that the form is simple, and you can use a SharePoint list form to capture the data, or a very lightly modified PowerApps form attached to a list. If that’s the case, then make the change today. Where you’re going to have to touch the form, you might as well see if you can get it converted quickly.

The big problem comes in the form of situations where there’s no clear answer as to how to convert an InfoPath form to PowerApps, because there’s no published guidance on how to do what you used to do in InfoPath inside of PowerApps or some other forms tool.

InfoPath Feature to PowerApps Conversion

Here’s where I get to be a shepherd again. First, we’re building a list of things you used to do in InfoPath (features, techniques, approaches) and the way to do them in PowerApps. The InfoPath to PowerApps conversion list is on the SharePoint Shepherd site. Go there and see if the thing you want to do is already listed.

Second, if you don’t see what you need on the list, send us an email at, and we’ll see if we can understand what you’re doing in InfoPath and how it might be done in PowerApps. Please feel free to send us an example of what you’re doing (but please don’t send your actual forms).

Finally, Laura Rogers has excellent resources for PowerApps training. If you’re interested, she’s got a PowerApps Basics course, or you can click here to see all the courses she has to offer.

Now Available: SharePoint Site Collection Security Strategy White Paper

Some of you may be familiar with a reference sheet that we mention often: our SharePointSecurityMatrix. While we’ve used this in the past to show the various permissions and permission levels in SharePoint, we haven’t really discussed what to do with this knowledge.

We’ve assembled the “SharePoint Site Collection Security Strategy” white paper to give you some more context. In this white paper, we explain how right assessment happens in most computer systems and how to view these basic principles through the lens of SharePoint security. We then talk about some ways to make security simple. We’ve also included step-by-step instructions for implementing the suggestions we offer. All you have to do is click the link below.

Get the SharePoint Site Collection Security Strategy white paper

Living the Legacy: Legacy Auth in Office 365

Recently I discovered a problem with a client’s tenant. All the sudden, the authentication that I’ve used for a decade to get my command line utilities to authenticate to work wasn’t working. But it was just this tenant. No other clients had the problem, so it was a mystery as to why things were happening. Getting to the answer caused me to fire up some old neurons and get some clarity on the way things worked.

Joining the WS-Federation

Many moons ago, when claims-based authentication was still new in SharePoint, I was speaking about claims-based authentication and how it worked. I was the contract CTO for a startup who was trying to solve the authentication problem in K12. I was also helping write some of the guidance for authenticating in SharePoint with this new approach. See Remote Authentication in SharePoint Online Using Claims-Based Authentication. So, this isn’t something that’s new to me, but it is something I haven’t focused on for a while.

As I was warming up the old neurons, I began to remember that the way we bounce from location to location and server to server is a standard called WS-Federation. It’s a “passive” authentication flow where the browser bounces from place to place to authenticate a user. Ultimately, the browser gets the user to a site that authenticates them, and the site issues a ticket. This is passed back through a chain of sites until you get back to the site that originally requested authentication of the user, all the while reissuing tickets. The article above explains the process in substantially more detail.

Ultimately, it’s all about one site (the relying party) trusting another site (the issuing party) to authenticate the user That’s all fine, but what do you do when you want to authenticate in a program instead of a web browser? Well that requires WS-Trust.

A little bit of WS-Trust

A different approach, an “active” flow, is needed to take care of programs that want to authenticate on behalf of a user but can’t follow a series of redirects. Think about the program that’s calling an API: it expects the results, not a series of redirects, so WS-Federation won’t work. The good news is that WS-Trust performs the same function as WS-Federation except that the server for the API makes the request for authentication on behalf of the user. The bouncing around is handled as the servers negotiate between each other where to go and whether the authentication succeeds.

The WS-Trust standard accommodates the normal case of a username and password to authenticate a user – but it has some serious limitations in a world where we’re beginning to use multifactor authentication.

Modern Authentication

Modern authentication, according to Microsoft and others, doesn’t rely on usernames and passwords. The idea is that we’re moving to a more secure platform where users need to authenticate with something more than a username and password. This is fine, except what do you do about authenticating programs that need to take action on their own behalf or on behalf of the user? The answer is effectively a username and password.

Some will argue that the shared secrets we give to applications aren’t passwords – after all, they’re called shared secrets, or keys, or something else. However, they amount to a password, but a substantially longer password than any user could ever manage. We’ve addressed the security problem by making the password sufficiently long.

In any case, we’re moving towards greater security, which includes multifactor authentication – and that can’t be accomplished in a username/password combination way. The result is that we call the simple username/password situation “legacy.”

When Legacy isn’t Legacy

Microsoft introduced a switch that you can turn off to disable “legacy” authentication. It makes sense at some level. There’s a new modern authentication that we want people to use, and, until recently, you needed to actively enable modern authentication. So, what do you call the old approach? Well, you call it legacy.

The problem is that legacy conveys that it’s old and should be replaced or disabled. And that’s what this client did. However, most utilities that allow for a user identity associated with the results created by the tool. When they disabled legacy authentication, they broke an entire class of applications.

Modern Application Authentication

In defense, there are new ways to authenticate applications into Office 365. However, what the labeling doesn’t make clear is that those modern authentication approaches only work for a subset of the APIs. Thus, there are some places where you don’t have a choice but to use the “legacy” authentication approach.

Certainly, should we be moving to modern authentication for our applications? Yes. However, it needs to happen when the APIs we need to access work with the new authentication. In this case, the new APIs would work – if we recode the tool we are using.

So at least in this case, “legacy” may mean today –even if we’re new to the platform.

Book Release: Secret SharePoint

We interrupt our normal schedule of book reviews to announce that we’ve released our latest book – Secret SharePoint. We’ve been leaking some content from the project for months on our blog, through a free subscription to an email series, and through partners like SPTechCon. This has been in preparation for our launch of the Secret SharePoint book – and that launch is today!

The book is over 200 pages of special tips that I’ve learned over the last 18 years of working with SharePoint. It’s solutions to hard problems, and they work whether you’re using SharePoint on-premises or SharePoint Online.

From birthday calendars and navigation to search and Word Quick Parts, Secret SharePoint has the solutions you need for the problems you’re facing.

More than that, we’re still offering the free email course that you can sign up for to get part of the content from the book and a newly-released, self-paced online course. Both of these offer not only the written text but videos and screen casts that walk you through the entire process of building the solutions that we’ve created for other customers.

As a special thank you for following us, you can get the book directly from us for $15 + Shipping. That’s half the retail price. Order yours today.

Microsoft Flow, SharePoint, 429, and Throttling a Workflow to Death

We’re here to mourn the death of many a workflow instance at the hands of SharePoint’s HTTP throttling. Except it’s not SharePoint’s throttling that is the true killer. SharePoint’s just the accomplice in this crazy dance that will get your workflows killed. Though it’s possible to protect your workflow instances from being throttled to death, it isn’t as easy as it might seem. In this post, we’ll talk about what happens every day and then what strategies you can use to protect your workflow.

Request Throttling

Before we can explain how a flow gets throttled to death, we first must understand a bit about throttling. Web servers are under constant assault from well-intended users, the code written by bumbling idiot developers (of which occasionally I am one), and malicious people. One of their defenses is to respond with “I’m too busy right now, come back later.” This comes back as the code HTTP status code 429. Sometimes these responses are kinder and will indicate when the person should come back. “Hey, I should be able to take care of that request for you after seven seconds” tells the program when it should retry the request – and here’s the kicker – expect that it will be able to be serviced.

The problem is that, when you’re dealing with so many different users and so many variables, it’s sometimes difficult to predict when the server will be willing or able to service a request.

Automatic Retries

Because a server may respond with a 429, most programs know to retry the request. The strategies vary but the default answer is an exponential interval. The first time you get a 429, you stop for a period of time – say four seconds – and then each time you retry, you square the interval. So, four seconds becomes sixteen on the second retry, and 256 seconds on the second interval. Flow allows you to follow the default policy, which is described as exponential, or explicitly set the interval to exponential. To do this, click the ellipsis at the right of the action and select Settings.

The action’s space in the flow will change to the settings view, where you can explicitly set the retry policy to exponential – which will further change the view to provide spaces for a maximum retry count, an interval, minimum interval, and maximum interval.

The default settings, however, are supposed to do exponential waiting on retries and four retries. So that seems like a good place to start. The default is implemented as one try plus three retries. That is how they get to four retries.

Retry Schedule Conflicts

What happens when there is a conflict between the provided retry schedule and what the server responded with as a part of its 429 response? The good news is that Flow will use the larger of the two numbers. In theory, at least, you’ll never hit a retry more than once or twice. Sure, the server could make a mistake with its guidance once but surely not twice. Unfortunately, that’s not always the case. Sometimes the response from the server – and the default exponential interval – will be too small, and you’ll exhaust the three retries and end up failing your request. This typically happens when you have multiple flows running at the same time.


Any given Flow may not be making that many requests, but what happens when there are many Flow instances running at the same time? If you do work on a queue that information is dropped into, you can’t necessarily control how many items will come in at the same time. With the scalability of the Flow platform, what’s to stop you from running hundreds or thousands of Flows at the same time – against the same poor server that’s just trying to cope?

If you have 100 Flows all starting in a relatively short time talking to the same back end server, it may be getting thousands of requests from Flow every minute. Even if each Flow is told to retry later, even the server telling the consumer to retry later may cause the server to need to push off work even further. The result is that every Flow gets throttled to death – until so few remain that they can be handled inside of the capacity of the server.

Luckily, Flow offers a technique for limiting the number of active flows at any time. This can be done by going to the ellipsis and then Settings for the trigger. This changes the trigger to its settings display, which allows you to limit the number of concurrent Flow instances – or the degree of parallelism.

SharePoint Request Throttling

Generic request throttling is fine but how does my favorite server – SharePoint – do it? Well, the answer isn’t clear. Microsoft published an article “Avoid getting throttled or blocked in SharePoint Online“, which says that they won’t publish the rules – because they’re changing them.

At the same time, they make clear that some of the criteria being used to manage the workflow are things like user agents, accounts, and App IDs. However, when it comes to Flow, we have some limitations.

Flows always run as the user that created the Flow – not as the user initiating the request. So, from the point of view of SharePoint, one user is making all the requests – and they’re making them from the same application, Flow. This makes Flows a high target for throttling, even when you consider it’s a well-known and well-trusted application.

It turns out there’s more to it than that. There’s an interface layer that the connectors – including the connector to SharePoint – use.

Connectors and Infrastructure

Many of Microsoft’s new offerings like Flow, PowerApps, and PowerBI need access to the same service data inside of multiple tenants. As a result, the connectors use a common architecture that allows multiple services to interact with Microsoft’s online service offerings. This architecture has its own throttling built in. It’s designed to protect the back-end services and has its own rules for throttling requests that’s more aware of the uniqueness of each of the fixed number of Microsoft internal consumers.

One of the things that this infrastructure can use to manage throttling is the connection to the service. In the first figure, you’ll notice two connections in the settings menu – with the same identity. This is one way that you can help the infrastructure avoid throttling you.

Multiple Connections

When there aren’t many things to differentiate requests on, the connection is one. It’s got its own identifier. Because of that, it’s easy for the back end to see which connection a request is associated with – and throttle too many requests from a single connection. Thus, if you want to help your Flow avoid getting throttled, you can make multiple connections to the same data source. This allows your requests to get spread across different thresholds and for more to get through.

The Fingerprints Match

For my case, the Flows were getting throttled not by SharePoint directly but through the infrastructure hub. I set the maximum degree of parallelism and assigned every action in the flow to a different connection, but it wasn’t enough. I didn’t set the retry settings manually, and the default settings continued to allow my poor Flows to be throttled to death by the infrastructure.

In the end, to spare more Flows from being throttled, we moved some of the data to Azure SQL. However, we saved many Flows just by adjusting the retry strategy and concurrency and creating multiple connections.


Setting Default Column Values

This solution will discuss how default column values to make it easier to enter metadata. By setting these default column values on a folder-level, it means any document added to that folder will get the same value in the column as the folder. We’ll walk you through how this works, first by setting up a library with some folders, then adding a column that will hold the desired information, and finally configuring the default column value settings on individual folders.

Task 1: Set Up the Library App

This task will lay the groundwork for default column value settings. We need to set up a library and create a couple of folders in the library.

1.    In a web browser, navigate to the SharePoint site where you want to create the library. The site’s home page will open.

2.    In the Suite bar, in the upper-right hand corner of the page, click the gear icon. The actions menu will open.

3.    Click Add an app. The Your Apps page will open.

Figure 1: The Your Apps Page

4.    Click on the Document Library tile. This is normally found under Noteworthy, but you can search for it as well. Click the “Find an app” search box, type library, then press Enter. Matching results for “library” will appear. You can then click Document Library. The Adding Document Library dialog box will appear.

5.    In the Name field, type a name for the library app. For this example and for the rest of the document, we’ll use the name Sales.

Figure 2: The Adding Document Library Dialog Box with the Sales Name

6.    Click Create. The Sales library will be created, and you’ll be taken to the Site Contents page.

7.    In the site contents listing, click Sales. The Sales library’s default view will open.

Figure 3: The Sales Library’s Default View

8.    In the command bar, click New. The New menu will appear.

Figure 4: The Expanded New Menu

9.    Click Folder. The Folder dialog box will appear.

10.    Type a name for your new folder. For this example and for the rest of the document, we’ll use Company A.

Figure 5: The Folder Dialog Box with the Company A Name

11.    Click Create. The Company A folder will be added to the Sales library.

12.    Repeat steps 8-11 to create another folder. For this example, we’ll use the name Company B. The Company B folder will be added to the Sales library.

Figure 6: The Company A and Company B Folders in the Sales Library

Task 2: Associate Site Columns to the Sales Library

Now that the library is set up, we need to create a column that will hold our metadata. For this example, we’ll use a custom site column we’ve already created. For more guidance on creating site columns, please see the SharePoint Shepherd’s Guide for End Users task, “Create a Site Column.”

1.    On the Sales library’s default view, in the Suite bar, click the gear icon to open the actions menu.

2.    Click Library settings. The Sales library’s settings page will open.

Figure 7: The Sales Library’s Settings Page

3.    Towards the bottom of the page in the Columns section, under the list of columns, click Add from existing site columns. The Add Columns from Site Columns page will open.

Figure 8: The Add Columns from Site Columns Page

4.    In the Select Columns section, under Select Site columns from, select the site column group that your site column is categorized as. For this example, we’ll select the Secret SharePoint site column group.

Figure 9: The Site Columns in the Secret SharePoint Group

5.    Under Available site columns, select a site column to add to the library. For this example, we’ll select Company Name. Then click Add. The site column will be added to the Columns to add box.

Figure 10: Company Name Selected as a Column to Add

6.    At the bottom of the page, click OK. The site column will be added to the Sales library, and you’ll be returned to the library’s settings page. In the Columns section, the Company Name site column will be listed along with the library’s default site columns.

Figure 11: The Company Name Site Column in the Columns Section

Task 3: Set Default Column Values

Now that we have the column and the folders set up in the library, we can set the default values for the column.

1.    On the Sales library’s settings page, under General Settings, click Column default value settings. The Change Default Column Values page will appear.

Figure 12: The Change Default Columns Values Page

2.    On the left side of the page is the menu Location to configure. Under Sales, the folders Company A and Company B are listed. Click the Company A folder. The page will refresh, and the breadcrumb bar will show Company A.

Figure 13: Company A Selected to Configure Default Column Value Settings

3.    Under Column (click to edit default value), click Company Name. The Edit Default Value dialog box will appear.

Figure 14: The Edit Default Value Dialog Box

4.    In the Default Value section, click the radio button for Use this default value.

5.    Under Default value, type the desired default value for this column. For this example, we’ll type Company A.

Figure 15: The Default Value Set to Company A

6.    Click OK. The Edit Default Value dialog box will close, and the page will refresh. Now, whenever a document is added to the Company A folder, the Company Name column will automatically get the value Company A.

Figure 16: Company A’s Company Name Set to Default Value “Company A”

7.    Repeat steps 2-6 for Company B. On step 5, type Company B. When you’re finished, whenever a document is added to the Company B folder, the Company Name column will automatically get the value Company B.

Figure 17: Company B’s Company Name Set to Default Value “Company B”

8.    In the breadcrumb bar, click Settings. You’ll be returned to the Sales library’s settings page.

9.    In the breadcrumb bar, click Sales. You’ll be returned to the Sales library’s default view.

Task 4: Add Documents the Sales Library

Now that we’ve added the default values to the column for the Company A and Company B folders, we’ll add a couple of documents to the folders. We won’t worry about the document names for this example, but you can direct users to follow these steps when adding documents to the library.

1.    On the Sales library’s default view, click Company A. The contents of the Company A folder will appear.

Figure 18: The Company A Folder

2.    In the command bar, click New. The New menu will appear.

3.    Click Word document. Depending on your library’s settings, Microsoft Word will launch, and a blank document will appear. Your settings may also cause Word Online to launch.

4.    Since we’re just showing how metadata is populated, we don’t need to change anything about the document. Return to the Company A folder. If Microsoft Word launched, close the document. If Word Online launched, in the Suite bar, click Company A. You’ll be returned to the Company A folder.

5.    The new document will be visible in the item listing of the Company A folder. In the Company Name column, the value will be automatically populated with Company A.

Figure 19: The New Document with Company Name Populated with “Company A”

6.    Return to the root folder by clicking Sales in the breadcrumb bar. The Sales library’s default view will appear.

7.    On the Sales library’s default view, click Company B. The contents of the Company B folder will appear.

8.    Repeat steps 2-4 to create another document in the Company B folder. When you return to the Company B folder, the new document will appear in the item listing, and Company B will be automatically populated in the Company Name column.

Figure 22: The New Document with Company Name Populated with “Company B”

cookie production

Using Word Quick Parts with a Custom Content Type

This solution walks you through the process of adding Quick Parts to the default template of a custom content type. This way, anyone who selects that content type from the library will create a new form with those Quick Parts added already. By filling out the Quick Parts fields, the metadata for that document will also be filled out in the corresponding SharePoint columns.

The step-by-step will assume you already have a library and custom document content type prepared. For more information on associating content types to a library, please see The SharePoint Shepherd’s Guide for End Users tasks “Create a Library App” and “Edit List or Library App Content Types.” For our example, we’ll use a library called Resources with the content type Invoice, which uses site columns Invoice # and PO #.

Task 1: Create a Content Type Template

This task walks you through drafting and editing the default template for your content type. In our example, our content type is for invoice forms, and we already have the form designed. We just need to add the Quick Parts, then save the document as a template. We’ll save it locally, which will allow us to access it when we edit the content type’s default template later.

1.    In a web browser, navigate to the SharePoint library that has your content type. For our example, we’ll go to the Resources library. The library’s default view will open.

2.    In the command bar, click New to open the drop-down menu.

Figure 1: The Expanded New Menu

3.    Select the custom content type. For our example, we’ll select Invoice. Depending on your library’s settings, Microsoft Word will launch.

Note: Depending on your settings, Word Online may launch. At the top of the Word Online window in the ribbon, click Edit in Word. The We’re opening this in Microsoft Word… dialog box will appear, and Microsoft Word will launch.

4.    If it isn’t already designed, design your form or copy and paste in the contents of an existing form. For our example, we already have our invoice form prepared, so we’ll copy and paste it in.

Figure 2: The Invoice Form in the New Document

5.    Click the Insert tab to open the Insert ribbon.

6.    Find a location on the document that will contain the information you want to send to SharePoint. For our first example, we’ll use Invoice #, which is found in the upper-right corner of the form. Because we want to place invoice numbers to the right of Invoice #, click the area to the right of Invoice # to move the insertion point there. If there is existing placeholder text, delete it now.

Figure 3: The Insertion Point to the Right of Invoice #

7.    In the Insert ribbon’s Text section, click the Explore Quick Parts icon. The icon looks like a page that has multiple boxes of content in different colors. The Quick Parts menu will appear.

Figure 4: The Explore Quick Parts Icon

8.    Hover over Document Properties, and a list of the document’s properties will be displayed. You should see both the default document properties, such as Author, Title, and Tags, as well as the names of the site columns associated to the content type.

Figure 5: The Document Property Menu

9.    Select the site column you want to add as a Quick Part in the document. For our example, we’ll select the Invoice # site column. The Invoice # site column will be added to the form as a Quick part. It’ll be displayed as a gray text box with the site column’s name in square brackets, such as [Invoice #].

Figure 6: The Invoice # Quick Part in the Template

10.    Repeat steps 6-9 to add other Quick Parts to the form in the desired locations. For our example, we’ll also add the PO # site column. Our location for purchase order numbers is in the table on the middle of the page, under PO#, so we’ll click the blank table cell, then select PO # from the Quick Parts menu. This will add the PO # Quick Part to the form.

Figure 7: The PO # Quick Part in the Template

11.    When you’re finished adding Quick Parts to the template, click the File tab to open the Info screen.

Figure 8: The Info Screen

12.    Click Save As. The Save As screen will appear.

Figure 9: The Save As Screen

13.    Click Browse. The Save As window will appear.

Figure 10: The Save As Window

14.    Give an identifiable name to the form. For our example, we’ll save it as InvoiceTemplate.

15.    In the Save as type field, click the drop-down menu, then select Word Template. The file type will change to .dotx. The Save As window will automatically change to show the Custom Office Templates folder on your PC.

16.    In the Navigation menu, click Desktop. You can usually find the desktop in the Quick Access menu. The contents of the desktop will appear in the Save As window.

Figure 11: The Invoice Template Ready to Be Saved on the Desktop

17.    Click Save. The Save As window will close, and the new form template will be saved to the desktop. You can now close the Word document.

18.    In your browser window, return to the library app’s default view, if it’s not already visible.

Task 2: Edit the Content Type’s Default Template

Our next step is to update the content type’s default template and use the new template we created with Quick Parts.

1.    On the library’s default view, in Suite bar, click the gear icon to open the actions menu.

2.    Click Site settings. If Site Settings isn’t visible, you may need to navigate to the Site Contents page first, then in the command bar, click Site Settings. The Site Settings page will open.

Figure 12: The Site Settings Page

3.    On the Site Settings page, under Web Designer Galleries, click Site content types. The Site Content Types page will open.

Figure 13: The Site Content Types Page

4.    On the right side of the page, next to Show Group, click the drop-down menu and select the site content type group that has your content type. For our example, our Invoice content type is found in the Secret SharePoint site content type group, so we’ll select Secret SharePoint. The Site Content Types page will refresh to show only the site content types in the selected site content type group.

Figure 14: The Secret SharePoint Site Content Type Group

5.    Click the custom content type. For our example, we’ll click Invoice. The Site Content Type page will open.

Figure 15: The Site Content Type Page for Invoice

6.    Under Settings, click Advanced settings. The Advanced Settings page will open.

Figure 16: The Advanced Settings Page

7.    In the Document Template section, select the Upload a new document template option. The Upload field will become enabled.

8.    Click Browse. Your browser’s file upload window will open.

Figure 17: The File Upload Window

9.    Navigate to the desktop, then click the name of the form template, such as InvoiceTemplate.dotx. The file name will appear in the File name field.

10.    Click Open. The file upload window will close, and the file path will appear in the Upload a new document template field.

Figure 18: The New Template Ready to be Uploaded

11.    At the bottom of the page, click OK. You’ll be taken back to the Site Content Type page. The new form template’s file will be uploaded as the default template for the custom form content type. Every time a user selects the content type from the New menu in the library, a new document will be created based on the form template with the Quick Parts added.

Task 3: Populate Metadata Using Quick Parts

This final task will show you how information added to the Quick Parts will be added to SharePoint without typing the information twice. You can instruct users to use these steps whenever they fill out their form.

1.    If you aren’t already on the library’s default view, navigate to the library now. For our example, we’ll navigate to the Resources library.

2.    In the command bar, click New. The New menu will appear.

3.    Click the name of your content type. For our example, we’ll click Invoice. Depending on your library’s settings, Microsoft Word will launch, and the default document template will open.

Note: Depending on your library’s settings, Word Online may launch. At the top of the Word Online screen, click Edit in Word. The We’re opening this in Microsoft Word… dialog box will appear, and Microsoft Word will launch.

Figure 19: The New Invoice

4.    Fill out the fields of your form.

5.    When you get to a field that contains a Quick Part, you’ll see a gray text box with the name of the field in square brackets, such as [Invoice #]. To fill out these fields, click into the Quick Part, then type the information. For the Invoice # example, we’ll type LL-002.

Figure 20: The Invoice # Quick Part with LL-002

6.    Repeat step 5 for every Quick Part in the form. For our example, we’ll also fill out the P.O. Number field. We’ll click the Quick Part, then type PO-200.

Figure 21: The PO # Quick Part with PO-200

7.    When you’re finished filling out the fields, save your document. Click the File tab to open the Info screen.

8.    Click Save As. The Save As screen will appear.

9.    Under Current Folder, click Resources. The Save As window will open.

10.    In the File name field, give a unique name to your document. For this example and for the rest of the document, we’ll use the name Invoice LL-002.

Figure 22: Invoice LL-002 Ready to Be Saved

11.    Click Save. The document will be saved to the Resources library, and the information you entered into the Quick Parts will now be added to the site columns of the document library as properties of the document.

12.    Close the Word document. If Microsoft Word was initially launched instead of Word Online, your browser window should show the library’s default view.

Note: If Word Online was originally launched, you should see the Word Online window instead of the library’s default view. To navigate back to the library app, in the Suite bar to the left of the document’s name, click Resources. You’ll be returned to the library app’s default view.

13.    Your document will appear in the item listing with the metadata populated in the columns. For our example, you’ll see the Invoice # field contains LL-002 and the PO # field contains PO-200.

Figure 23: Invoice LL-002 with the Populated Metadata