If you created a Merged helpset, you could structure it so that the components that are merged in are placed in different folders. Then password protect those folder or otherwise restrict them so that only validated users could see them. When the master is launched, if it cannot get to one or more child projects, they aren't listed in the Table of Contents and in the Index and Search.
I suggested this years ago for a product where I was the tech writer. The owner of the company decided on a different approach. His view?
Since they can't do the functions the help is for anyway, what does it hurt to have it available? Further, if they haven't yet purchased a module that they have help for, perhaps by seeing the help, it will help serve as a marketing tool. By seeing what is possible via the help, perhaps they might be encouraged to purchase additional modules.
Helpful and Handy Links
I'm new'ish to this forum and tried to provide more detail in my original post, but apparently I'd already posted and so could not edit the post .
I will share your comments with the application developer, who is wondering how best to show child projects only to validated users.
I've always worked at companies where all the Help was included, as a way to showcase all the features, as you note in your reply. However, at my current company there are good reasons not to do this.
If you know of any good reference documentation for me and the developer to use while implementing this type of WebHelp, I would appreciate your sharing the information with me.
Do you have any thoughts about how best to structure this type of project? Here are two design ideas I've been working on.