There is no globally-applicable answer to the "single monolithic help file" vs "context-based help" question: as with so, so many UX issues, it depends on the type and complexity of the app itself, on the quantity of help text to be supplied to the user, and on the type of user and their level of expected familiarity with the application. Either strategy might be appropriate, depending on the specifics of your application; each has advantages and disadvantages you'll need to consider when making this decision.
Ultimately the goal is to get the user the help they need, with a minimum amount of digging through stuff they don't (at the moment) need.
(This applies to anything from a single help page, to a separate structured help site with its own subnavigation.)
Advantages: easy to find, always in the same place. Least amount of interface clutter (just one button). User has the ability to read through the entire help file(s) if they choose to, to familiarize themselves with the overall structure of the application, or to search through the help text to find every mention of a given topic. Lends itself well to help text that is conceptual ("here's what this feature does, and why") rather than UI-specific ("here's what you need to click to perform this task"). Allows for cross-reference, searchability, topic indexes, and so forth.
Disadvantages: Uncontextualized. The user has to leave the context of their task, find the particular section of a (potentially large set of) help text that contains the information they need, then find their way back to the task. Monolithic: in large applications, many users only care about a subset of the functionality, or you may have different types of users each with their own needs. A monolithic help file works against this; you can't easily tune the help text to different user types, for example, or omit information for one group of users that may only be relevant for a different group of users; this tends to be less of an issue with context-based help because there the user's context naturally leads them towards the relevant information and away from the irrelevant.
(But note: In your specific case, since your product is configurable to omit certain features, the help file or files should follow this configuration: if a given instance of the product doesn't have a Work Queue portlet, then any section of the help text that references the Work Queue should be omitted from that instance.)
Suitability: In general, monolithic help is more suitable for more complex applications, and those with a relatively low-churn userbase: individual users new to the app can read through whichever portions of the help files they need to familiarize themselves with the overall structure; once they have a handle on things they can ignore the help link, or only refer to it for obscure or unusual tasks, and won't have a bunch of separate context-help icons getting in their way.
Advantages: context-based (obviously). The user has a question about a thing, there's a help button on that thing, which tells them how to use that thing.
Disadvantages: Demands brevity. Contextual help needs to be very specific to the related task, there's not a lot of room for cross-reference or discussion of the higher-level structure of the application. Potential for interface clutter (lots of separate help buttons). No cross-reference or easy searching of text is possible. Help which may relate to more than one feature needs to be applied to every one of those features, which can feel repetitive. Help which relates to interactions between multiple features tends not to fit well in this model.
Suitability: In general, contextual help is more suitable for simpler applications, where the help to be provided is more of the quick-hint variety -- if your help text is mostly of the "how to use this particular screen widget", putting that help in the context of that widget is very useful. Applications with lots of user turnover tend to be suited to context-based help (because there is a greater likelihood that a given user will be new to the app and not know what's going on.)
What not to do
Don't try to split the difference, or disguise one type of help as the other, or do both at once. If your help text is long and complex, don't stuff it into contextual popup windows. If your help text is highly widget-specific, don't make the user dig through a set of navigation in a separate help site to find the relevant widget they were looking at in the first place. Don't include tautological or space-filler help: if a given widget is self-explanatory, don't add a context-help link to it just because six of its neighbors have one too. (Remember the best kind of help is not needing help in the first place: as much as possible your interface should be intuitive without the user needing to "read the manual".)