I see, yes having numbered headings in the text body does complicate matters, as it sounds like they are perhaps being used relatively rather than absolutely. For example, say we have this binder outline:
Draft
Part I
Chapter 1
Some Text
More Text
Chapter 2
More Text
All right, now seeing as how “Heading 1” is the top level style, we would expect that to be applied to “Part I”. But it sounds like you have it in the text itself somewhere, presumably way deeper? I don’t know. So in effect the compiled stylesheet outline you are building looks incoherent once the body text headings are inserted, like this:
Draft
Part I
Chapter 1
Some Text
Some Text's Heading
More Text
More Text's Heading as well
Maybe it has two H1 headings
And an H2 heading in the text (chapter level!).
Chapter 2
And More Text
And More Text's Heading
Does that make more sense? Maybe you’re doing all of this right though. Of course what you’d really want is for the headings in the chapter’s text items to be either H3 (if these text chunks have no heading of their own), or H4 if the text chunk is printing an H3 heading for itself. Like this:
Draft
Part I
Chapter 1
Some Text
Some Text's Heading
More Text
More Text's Heading as well
Maybe it has two H4 headings
And an H5 heading.
Chapter 2
And More Text
And More Text's Heading
That is more like what you’re going to want to see in the word processor’s navigation sidebar.
But there are more complications. By putting numbered headings into the text body with the intention of importing the stylesheet outline back into Scrivener later, the second outline is what you’re going to see imported! Each subsection will be indented in its own document beneath the “Some Text” level items they came from. That wouldn’t be the end of the world, Scrivener is designed to work with very detailed outlines, but it might be more outlining than you prefer.
So one way around this pickle is to simply rename your body text styles. Scrivener wants them to be called “Heading 1” &c, so if they are anything else then they are not going to be part of the formal document outline. Even if you just do that temporarily, I suspect that will by far be the easiest thing. You can then proceed to use the prior instructions which inject levelled headings based on your literal outline structure, purely for the purpose of later importing a nested outline and stripping them out.
You can blend the two methods, as I demonstrated in the previous outline, just so long as you keep coherency in mind and use the right level of heading in the body of the text.
I wrote a bit about this topic in this thread. The main point of conversation there was getting good styled output so that a ToC could be added in the word processer. What that isn’t your goal, the road to getting there is identical to what you need, because what makes for a good indented ToC is exactly the same thing Scrivener will be using to import a nested outline from the document’s stylesheet.
It’s a personal choice, whether to do that or not. I myself would not because I prefer a fluid outliner to baked in document structure as a function of the text. I don’t like that in Markdown text either, where we mark headings generically, like “### Level 3”. It’s just stuff I have to manually fix if I want that to become a chapter, as opposed to just outdenting it.
Still not clear whether those Headings in Project ▸ Project Settings… are additional to the text formatting paragraph headings in the text itself.
So specific to this, those are not headings. We might certainly choose to use implement them that way, and in this particular case we are, in order to achieve a specific effect of making your outline round-trippable—but section types can be anything and by themselves they have no implementation, they are purely a name. They don’t even have to be stuff that compiles.
All they are, quite simply, is a way of saying this binder item here is that type of thing. This is one of those things that really sets Scrivener apart from many other outliner-based tools. Each level in the outline can have semantic meaning, and we can also manually assign such semantics to items by hand as well. Even if we don’t use them to compile, they can be useful simply for being a thing, like a section marked “Figure”. If you put all of your figures into binder items tagged with that Section Type, then you can run a search for the “Figure” section type and get a list of figures. You can load a corkboard and then have it filter out all of the items using the type, “Notes to Self”.
When it comes to compile it is entirely based around these types. That is where you can say what a “Part” should look like in the document, what heading level it should be maybe, or if a “Figure” item should print the binder title beneath the image using the Caption style. Or in other words: its implementation.
We’re a bit in the weeds here, but the important thing to note is that your outline can be typed, and you can take those types and assign them to “layouts” in the compiler, which work like printing templates. We are using that capability here to do something unorthodox, something you need for a specific “throwaway” purpose. It is perhaps in that regard a great example of the power of this system in that you can do that, and then later take the same exact binder outline structure and have it print like a book rather than a raw outline feed with brightly colour-coded headings.
While this is all quite a lot to run a search and replace in another program, it’s all solid learning material as this is good stuff to get a grip on. It will make Scrivener much easier to use.