What is the difference between Populate Solr Managed Schema & Indexing Manager features

Question

Please help me understand these features.

1. What is the difference between these two features in the control panel - Populate Solr Managed Schema & Indexing Manager?
2. When to use which?
3. How often should I rebuild the index. Is it after every template/rendering/content creation.

I have created some content items under /sitecore/content. These are from different templates.

In the Solr portal, only few of them show up and the rest don't. I have rebuilt the indexes for both the features.

Answer 1

Managed Schema

This is needed after adding a new index/core or when new field types are configured in the Sitecore config. Many of the fields are dynamic so you may rarely run this.

I added Managed Synonyms to the text field which required the schema to be repopulated; this is because all of the schema data needs to be resent to Solr.

As you can see below, the schema for the sxacontent field is dynamic ergo the _*txm in the name.

Expect to run this for new installations, crawling config changes, or when the current schema is missing something.

Indexing Manager

This is needed any time templates are added/modified. Imagine you have documents with Title and Text. If you add a new template field for Metatitle then none of the existing documents will have this new field

Only rebuild indexes that need it. I like to have a custom index per site or line of business; this allows me to restrict the crawling to specific parts of the tree. The OOTB indexes like sitecore_web_index are rooted at /sitecore which means it could take far more time than necessary.

Example: The following demonstrates how to reduce the scope of the crawlers (and remove the original). In my case I don't actually use sitecore_web_index and sitecore_sxa_web_index because there are custom indexes for each line of business.

<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:set="http://www.sitecore.net/xmlconfig/set/" xmlns:role="http://www.sitecore.net/xmlconfig/role/">
  <sitecore role:require="Standalone or ContentManagement or ContentDelivery">
    <contentSearch>
      <configuration>
        <indexes>
          <index id="sitecore_web_index">
            <locations>
              <patch:delete />
            </locations>
            <locations hint="list:AddCrawler">
              <crawler name="templates" type="Sitecore.ContentSearch.SitecoreItemCrawler, Sitecore.ContentSearch">
                <Database>web</Database>
                <Root>/sitecore/templates</Root>
              </crawler>
              <crawler name="content" type="Sitecore.ContentSearch.SitecoreItemCrawler, Sitecore.ContentSearch">
                <Database>web</Database>
                <Root>/sitecore/content/home</Root>
              </crawler>
            </locations>
          </index>
          <index id="sitecore_sxa_web_index">
            <locations>
              <patch:delete />
            </locations>
            <locations hint="list:AddCrawler">
              <crawler name="templates" type="Sitecore.XA.Foundation.Search.Crawlers.SxaItemCrawler, Sitecore.XA.Foundation.Search">
                <Database>web</Database>
                <Root>/sitecore/templates</Root>
              </crawler>
              <crawler name="content" type="Sitecore.XA.Foundation.Search.Crawlers.SxaItemCrawler, Sitecore.XA.Foundation.Search">
                <Database>web</Database>
                <Root>/sitecore/content/home</Root>
              </crawler>
            </locations>
          </index>
        </indexes>
      </configuration>
    </contentSearch>
  </sitecore>
</configuration>

If you use SwitchOnRebuild you could end up rebuilding twice to ensure consistency between the two Solr cores.

Based on your indexing strategy you may see the rebuild happen automatically following large volumes of content changes.

Expect to run this following deployments which include template or search config changes. A change in the list of crawlers could result in a reduction/increase in records. I managed to shave 250 MB from a Solr core by eliminating unnecessary documents.