My original goal was to dynamically enable the SiteFeed feature in a dynamically created publishing sub web. This has been accomplished and works like a charm.

Information on how to do this was found pieced together via these posts: How to enable publishing feature using CSOM? and https://stackoverflow.com/questions/17803291/failing-to-activate-a-feature-using-com-in-sharepoint-2010. Note that the latter filled the gap regarding enabling existing web features using:

this._newWeb.get_features().add(new SP.Guid('15a572c6-e545-4d32-897a-bab6f5846e18'), true, SP.FeatureDefinitionScope.none);

The important bit is that enabling pre-installed web features requires FeatureDefinitionScope.none.

All of this got me to thinking: why not enable a feature deployed via a no-code sandbox solution? Here's my basic code:

 var newWebCreationInfo = new SP.WebCreationInformation();
        newWebCreationInfo.set_description('Created Using CSOM');

        this._newWeb = this._hostWeb.get_webs().add(newWebCreationInfo);
        // this._newWeb.set_customMasterUrl(masterPageUrl);

        // Activate SiteFeed Feature -- This works totally fine
        this._newWeb.get_features().add(new SP.Guid('15a572c6-e545-4d32-897a-bab6f5846e18'), true, SP.FeatureDefinitionScope.none);

        // Activate ProjectPortal.NCSS Feature - this fails
        this._newWeb.get_features().add(new SP.Guid('d3f51582-abcf-483a-9414-d4976a5094ae'), true, SP.FeatureDefinitionScope.none);

        // Do the execution ...

Seems like it should work, right? Problem is, I'm getting the following error:

Request failed. Feature with the id 'd3f51582-abcf-483a-9414-d4976a5094ae' is not installed in this farm, and cannot be accessed to this scope.

The feature is in a SandBoxed solution, and is currently set at the web scope.

Anyone have success doing this?

1 Answer 1


Not long after posting this, I got it to work.

 // Activate ProjectPortal.NCSS Feature - this fails
    this._newWeb.get_features().add(new SP.Guid('d3f51582-abcf-483a-9414-d4976a5094ae'), true, SP.FeatureDefinitionScope.site);

Changing the SP.FeatureDefinitionScope to .site seemed to be the key. How that works from a pure naming convention standpoint is beyond me. My theory is that SP.FeatureDefinitionScope indicates where the feature resides in SharePoint, not where it's being activated.

Given all of this, let's reflect a bit. When enabling features on newly created sub webs:

  • Use SP.FeatureDefinitionScope.none to enable a web-scoped built-in SharePoint feature (e.g. SiteFeed).

  • Use SP.FeatureDefinitionScope.site to enable a web-scoped featured deployed via NCSS solution (e.g. my custom built ProjectPortal.NCSS feature).

  • Use SP.FeatureDefinitionScope.web to ... ??


I found when deploying this to a SharePoint Online instance that adding the feature was giving me the same "unable to find feature id" message, no matter what the enumeration was set to.

Turns out, the solution was deployed at the root-level in SharePoint Online, not at the site-collection level where the feature was being enabled.

So for example, let's say my instance is: https://foocompelsyou.sharepoint.com. Deploying the NCSS at this level causes the .add() method to fail, no matter the FeatureDefinitionScope setting.

Deploying the NCSS at the site collection level, let's say https://foocompelsyou.sharepoint.com/sites/mysitecollection allows it to work as discussed above.

Isn't this magical? :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.