Upgrading from a version prior to 2.7.33.0.

Applies to: NITRO Studio for SharePoint Server 2016 / 2019 / Subscription Edition (SE), on-premises. One-time upgrade steps for SharePoint administrators.

Who should use this document. This guide covers the one-time steps required to move an existing NITRO Studio farm from a version prior to 2.7.33.0 to a version that is 2.7.33.0 or higher. It is deliberately separate from the regular installation and upgrade documentation because these steps only apply when moving across this architecture change and do not need to be repeated on later upgrades. Work through Part B in order. Part C (Windows Services) is optional and can be done preferably in a later upgrade cycle. For a normal upgrade to a new NITRO package release (with no such architecture change), use the separate article NITRO Studio Routine Upgrade Guide. For fresh installation, refer to NITRO Studio Installation Guide.

Before you begin

• Permissions. You must be a SharePoint Farm Administrator. The setup tool checks this at launch and will not run otherwise.
• Where to run. Run the latest NITRO Studio Helper tool (NITROHelper.exe) on a SharePoint server in the farm (WFE or application server) with the SharePoint Server Object Model available.
• Timing. Plan a maintenance window. Solution deploy/retract steps stop and start SharePoint services and recycle IIS. A content database backup is not necessary but can be done as a precaution.
• Close browsers. Close open NITRO configuration pages so cached scripts reload after the upgrade.

The new settings menu

A new settings button has been added near the top-right of the setup tool’s main window. Clicking it opens a menu with the three new management screens used throughout this guide:

• Manage NITRO Solution — Deploy / upgrade / delete the NITRO farm solutions (Part B, Step 1).
• Manage Workflow Events — Set up list-level workflow events and relocate workflow log lists (Part B, Steps 2 & 3).
• Manage NITRO Services — Create the workflow timer jobs, and (optionally) switch to Windows Services (Part B, Step 4 and Part C).

Part A — Overview of the major changes

This release changes how NITRO Studio is deployed and how its background processing and front-end package are organized. The four changes below are described here at a high level; detailed steps follow in Part B.

A1. New deployment model for NITRO solutions

• When you upgrade, the tool deactivates the current NITRO features from every NITRO-activated site collection, then retracts the existing solutions, and finally installs and deploys the new solutions and reactivates the feature.
• NITRO Workflows is now deployed at the farm level. The Workflow Manager solution was previously scoped to individual web applications; it is now deployed globally.
• Only one NITRO feature is now activated at the site-collection level — the Crow Canyon NITRO Studio Feature. Activating it adds the NITRO buttons (and the Workflow Manager menu link) to the site’s gear (Settings) icon and the site menu. Everything else – creating lists and creating timer jobs – is now performed explicitly from this setup helper tool rather than as part of the feature activation. Wiring of workflow events is done at the time of creating workflows. Events will be set up for existing workflows with the tool.
• The Workflow Manager and Mail Template features are retired. The site link and menu entries that used to come from the Workflow Manager feature are now provided by the NITRO Studio feature’s own custom actions. The Workflow Manager solution no longer ships a feature of its own, and the Mail Template feature (which used to live in Common Utilities) is likewise retired. Both feature definitions still physically exist after the upgrade but are empty and inert — they no longer contain any custom actions, event receivers, or list/timer-job creation logic, so activating them does nothing.
• The Mail Template lists are now created by this tool. The lists the retired features used to create automatically (for example CCSWorkflowManagerSettings, CCSCommonMailTemplates, and CCSDocuSignRequests) are now created by the setup tool via the Apply NITRO Settings action when you set the package (Part B, Step 5).

Net effect after this step: NITRO Workflows is deployed farm-wide; only the NITRO Studio feature remains active at the site-collection level (adding the NITRO buttons and the workflow menu link to the site gear icon); the Mail Template and Workflow Manager features are inert; and list creation and timer-job creation are all driven from this setup tool (Steps 4 and 5). For the exact solution-by-solution and feature-by-feature breakdown, see “Full details of the solution and feature changes” at the end of this guide.

A2. Workflow events are set up at the list level; logs move to a subsite

• NITRO Workflow events are no longer wired up at the site-collection level by the feature. Instead they are set up per list. The new Manage Workflow Events screen walks through each workflow and, based on the workflow type, registers the correct list-level event. This is a one-time step for this upgrade. Going forward workflow events will be set up whenever a workflow is saved.
• Workflow log lists are moved into a dedicated “NITRO Logs” (URL: NITROLogs) subsite to reduce clutter in the main site’s Site Contents. Each site that uses NITRO Workflow logs will have a subsite ‘NITRO Logs’. After this change, workflows write their logs to lists in that subsite. This can be run for all site collections from the tool, or per site collection from the NITRO Workflows settings page (which also offers to clean up the old log list from the main Site Contents).

A3. Timer jobs are created from this tool, not on feature activation

• The timer jobs that process async, scheduled, and date/timer workflows for a site collection are no longer created via feature activation. They are created when NITRO Studio is installed in the site collection via this tool.
• One time setup of timer jobs for existing NITRO site collections is required during this upgrade. Create them from the Manage NITRO Services screen (or as part of setting Package Info).
• Optionally, you can process these workflows using Windows Services instead of a per-site-collection timer job. This is covered separately in Part C and is recommended only for a later upgrade cycle.

A4. Shared NITRO package per web application (optional)

• Previously the NITRO package (the CDN files — JavaScript, CSS, images, and other front-end files) was installed separately in every site collection. You can now keep the package in one site collection per web application and point all other site collections in that web application at it.
• You set this using Package Info on the tool’s main form, which writes property-bag entries that tell the NITRO apps where the package lives.
• This is optional. Site collections that currently use a local package continue to work. Moving to a web-application-level package speeds up future NITRO upgrades, but each affected site collection must be repaired/updated once so its apps point to the new package location.
• The package upload now uses MD5 checksums so a file in the package library is only re-uploaded when it has changed in the new NITRO package.

Part B — Required upgrade steps

Perform these steps in order. Steps 1-4 are required. Step 5 (shared package) is optional but recommended.

Step 1 — Upgrade the NITRO solutions (mandatory)

Open the settings menu and choose Manage NITRO Solution.

1.1 — Review current status

• Leave all three solutions checked (NITRO Studio, Workflow Manager, Common Utilities) — the All check-box selects them together.
• Click Get Status. The log pane lists farm/server information, each solution’s current state, and feature activation status. Use this to confirm you are on the correct farm before making changes.

1.2 — Run Install / Deploy Solutions

Install / Deploy Solutions is mandatory for this upgrade. Because the deployment model itself is changing (farm-level Workflows, retired Mail Template feature, single site-collection feature), you must run Install / Deploy Solutions at least once — the in-place Upgrade Solutions button is not sufficient for the initial move.

Click Install / Deploy Solutions. If the tool detects an older NITRO solution on the farm it shows an upgrade notice first — read it and click OK to continue. The tool then performs the full changeover automatically while streaming progress into the log pane:

1. Stops any NITRO Windows Services (if installed) so the assemblies are not locked.
2. Deactivates the NITRO features from every NITRO-activated site collection and removes the existing timer jobs.
3. Retracts and removes the existing NITRO solutions.
4. Adds and deploys the new solutions (in dependency order: Common Utilities → Workflow Manager → NITRO Studio).
5. Reactivates the site-collection feature that was previously active.
6. Verifies the deployment and shows a Deployment Summary (per-solution Success / Error).

The tool restarts itself at the end of this step. After a successful deploy, the tool saves its log and automatically relaunches so the newly deployed assemblies load into a fresh process. This is expected. When it reopens it shows the post-deploy status; if you were upgrading from an older solution it also shows a final upgrade notice. Wait for the restart to finish before continuing.

Confirm every solution shows Success in the Deployment Summary and that the log ends with a success message before moving on.

1.3 — Multi-server farms: ensure the solution reaches all servers

On farms with more than one SharePoint server, a deployment can occasionally fail to distribute the solution files to all servers. If you find NITRO is not working on some servers after deploying, use Install / Deploy Solutions again — because it performs a full retract and redeploy, it forces the solution to be re-distributed to every server in the farm. This is the reliable way to correct a partial/uneven deployment.

1.4 — When “Upgrade Solutions” is acceptable (later upgrades)

• Upgrade Solutions performs an in-place upgrade of the selected solutions — it does not retract, remove, deactivate features, or touch timer jobs. It is faster and less disruptive.
• It is appropriate for later, routine version updates once you are already on the new deployment model, and when you are confident the solution is present on all servers.
• It is not appropriate for this one-time upgrade, and not appropriate when you need to correct a partial multi-server deployment — use Install / Deploy Solutions for those.

Step 2 — Set up workflow events at the list level

Open the settings menu and choose Manage Workflow Events, then use the Events tab.

Prerequisite guard. These actions require the updated Workflow Manager solution. If you have not completed Step 1, the tool blocks the action with the message “The Workflow Manager solution is not updated… Please deploy the updated solution from the Deploy Solutions screen before performing this action.” (The Deploy Solutions screen referred to here is the Manage NITRO Solution screen used in Step 1.)

• Click Verify Events. The tool scans every web application and site collection, and for each site collection where NITRO is active it walks through the workflows and registers the correct list-level event receiver for each workflow, based on the workflow’s type. Progress and any per-site messages appear in the log pane; a summary of active vs. skipped sites is shown at the end. Note that this step will take some time as there could be many workflows across different site collections.
• Remove Events is available if you ever need to remove the Crow Canyon event receivers from all workflow lists across all site collections. You do not need this during a normal upgrade.

Confirm the run ends with a success message and review the log for any per-site errors.

Step 3 — Move workflow logs to the “NITRO Logs” subsite

Still in Manage Workflow Events, switch to the Logs tab.

• Click Verify Logs. For every site collection, the tool moves the NITRO workflow log lists into a dedicated “NITRO Logs” subsite. This declutters the main site’s Site Contents. After this change, workflows write their logs to the lists in the “NITRO Logs” subsite.
• The same relocation can be performed for an individual site collection from the NITRO Workflows settings page in that site. That page has an additional option to clean up the old log list from the main site’s Site Contents once the logs have been moved.

Running this from the tool applies to all site collections at once; use the per-site option on the settings page for targeted moves or to clean up an individual site afterwards.

Step 4 — Create the workflow timer jobs

Because timer jobs are deleted during this specific solution upgrade, you must create them explicitly after upgrading. Open the settings menu and choose Manage NITRO Services, then use the SP Timer tab.

• Click Verify Timer Jobs. The tool scans every web application and, for each site collection where NITRO is active, creates and verifies the required workflow timer jobs (the standard workflow job, the async job, and the DocuSign job). This is the button you use to (re)establish timer jobs on all NITRO-installed site collections.
• Check Timer Jobs lists the NITRO timer jobs found and whether each is enabled or disabled — useful to confirm the result of the verify run.
• Disable Timer Jobs / Delete Timer Jobs are used only when decommissioning timer jobs (for example, if you later move to Windows Services — see Part C). Delete asks for confirmation. You do not need these during a normal upgrade.

Staying on timer jobs is fully supported and is the default. Completing this step leaves NITRO processing your workflows exactly as before, using per-site-collection SharePoint timer jobs. Windows Services are an optional alternative you can adopt later (Part C).

Step 5 — Move to a web-application-level package (optional, recommended)

This step is configured on the tool’s main form (it is not under the settings menu). It lets a whole web application share a single NITRO package instead of each site collection carrying its own copy.

5.1 — Set the package scope

1. Select the Web Application and the Site Collection you are configuring.
2. In Package Scope, choose:
   • Site Collection Level — the package lives in this site collection (the previous behavior).
   • Web Application Level — the package lives in one nominated site collection and is shared by all site collections in the web application. Select the site collection that hosts the shared package.
3. Click Apply NITRO Settings. Confirm the details in the prompt. The tool then records the package scope and location (in the site collection’s property bag, and — for web-application scope — a matching farm-level entry for the web application), ensures the required NITRO lists exist, and creates the timer jobs if applicable.
4. Saved Package Info shows the currently saved scope and location for the selected site collection at any time.

The package site collection must be on the same host as the site collection you are configuring; the tool validates this and will warn if the host names differ. Host-named site collections need to keep the package at the site collection level to avoid CORS errors.

5.2 — Repair/update sites that move to the shared package

Moving an already-installed site collection to the web-application package requires a one-time repair/update. When you change a site collection from a local (site-collection) package to the shared (web-application) package, the tool warns that this “will require NITRO repair/update on all NITRO-activated sites in the site collection.” Perform that repair/update so the NITRO apps start referencing the new package location (JavaScript, CSS, images, and other files). Until you do, those apps still point at the old location.

5.3 — Faster uploads with MD5 checksums

• During package upload the tool compares an MD5 checksum of each file in the new package against the copy already in the package library, and skips files that have not changed. Only genuinely modified files are re-uploaded, which makes package updates noticeably faster.
• The main form provides an option to update only modified files (checksum-based) versus forcing a full re-upload of every file — use the full re-upload only if you suspect the library is out of sync.

Why do this. A shared web-application package means future NITRO upgrades update one location instead of every site collection, which — combined with the MD5 skip — significantly speeds up upgrades. It remains optional; site collections left on a local package continue to work.

Part C — Optional / later: Windows Services instead of timer jobs

It is recommended to do this in a later upgrade. Complete Part B first (new solutions, list-level events, log relocation, and timer jobs) and run on timer jobs for a while. Consider moving to Windows Services at a subsequent NITRO Studio upgrade, once the new deployment model is settled. Windows Services are entirely optional — customers may continue using timer jobs indefinitely.

C1. What the Windows Services are

Three Windows Services can replace the SharePoint timer jobs that run NITRO background workflows. Each service is a separate instance of the same executable, differentiated by its configuration file:

Service mode	Handles	Effective interval
Timer	Date-triggered (DateColumn) workflows	Every 30 min per site
Scheduled	Scheduled Query / Manual / Report workflows + DocuSign polling	Scheduled every 60 min per site; DocuSign every 60 min per site (offset 30 min)
Async	AsyncExecution workflows (rapid item changes)	Every 2 min per site

Minimum deployment: one Timer instance + one Scheduled instance + one Async instance. All three modes must run for full coverage.

C2. Trade-offs and risks (read before deciding)

• Timer jobs vs. services. Timer jobs run one job per site collection inside SharePoint’s own timer service. The Windows Services process many sites from a small set of dedicated services, which reduces the number of SharePoint timer jobs and gives you independent logging and control.
• Multi-server load sharing. Each mode can be deployed across multiple servers to share the site-processing load. This requires matching configuration on every instance of a mode (see C4): each instance needs a unique ServiceInstanceId, and every instance of that mode must share the same TotalServiceInstances value. When configured correctly, all instances of a mode log the same SharedHash.

Availability risk. Workflow processing is partitioned across the running service instances. If the service on one server goes down, the site collections assigned to that instance are not processed until the service is restored (or the configuration is changed and services restarted). Plan monitoring and automatic recovery (C4, Step 3) accordingly. With timer jobs, by contrast, processing follows SharePoint’s own timer service.

Configuration drift causes double-processing or gaps. If TotalServiceInstances or the slot interval differ between two instances of the same mode, some sites are processed twice and others never. Always verify the SharedHash matches across all instances of a mode after starting them.

C3. Switch the farm setting

Open the settings menu → Manage NITRO Services → the NITRO Service tab lets you choose how NITRO processes workflows for the farm:

• NITRO SharePoint Timer Service (default) — use the per-site-collection timer jobs from Part B, Step 4.
• NITRO Service (Windows Service) — use the Windows Services described here.

Choose the option and click Save to record the farm setting. When the NITRO Windows Service option is enabled, the tool no longer creates per-site timer jobs when you apply settings. The same screen lets you Install / Remove the services and Start/Stop each one; it also shows live service status. Note that timer jobs across the farm can be easily created/deleted from the tool with a click of a button.

The tool can install and manage the services for you on the local server. The manual procedure below (C4) documents the same result and is what you use to deploy additional instances on other servers for load sharing.

C4. Full manual installation steps

Prerequisites

• NITRO Workflows already installed on the farm (GAC contains CrowCanyon.WorkflowManager.dll and CrowCanyon.CommonUtils.dll) — i.e. Part B, Step 1 is complete.
• .NET Framework 4.6.2 or later on each service host server.
• Service account with the Log on as a service right and SharePoint Farm Administrator rights. Using the same account as SPTimerV4 is simplest.
• The host must be a SharePoint WFE or application server (the service calls the SharePoint Server Object Model directly).

Files to deploy

Build NITROWorkflowService in Release and copy these files from bin\Release\ into each instance folder:

NITROWorkflowService.exe
NITROWorkflowService.exe.config     ← edit this per instance
NITROServices.Common.dll
NITROServices.Common.dll.config     ← do not edit
Newtonsoft.Json.dll
Serilog.dll
Serilog.Enrichers.Thread.dll
Serilog.Sinks.Console.dll
Serilog.Sinks.File.dll
System.Buffers.dll
System.Diagnostics.DiagnosticSource.dll
System.Memory.dll
System.Numerics.Vectors.dll
System.Runtime.CompilerServices.Unsafe.dll
System.Threading.Channels.dll
System.Threading.Tasks.Extensions.dll
System.ValueTuple.dll

Do not copy: .pdb, .xml, App.config, or the GAC assemblies (CrowCanyon.WorkflowManager.dll, CrowCanyon.CommonUtils.dll, Microsoft.SharePoint.dll — already deployed by the NITRO installer).

Folder layout — one folder per instance

Create one folder per service instance; never share a folder between instances. Recommended: C:\NITROServices\{Mode}-{N}\

C:\NITROServices\
├─ Timer-1\        (Timer service, instance 1)
├─ Scheduled-1\    (Scheduled service, instance 1)
└─ Async-1\        (Async service, instance 1)

For two instances of a mode across two servers, deploy one folder per server (e.g. Timer-1 on Server A, Timer-2 on Server B).

Configure NITROWorkflowService.exe.config (per instance)

Settings that differ per instance:

Key	Description	Example
ServiceMode	Mode this instance runs	Timer, Scheduled, or Async
ServiceInstanceId	1-based ID, unique across the whole farm	1, 2, …
TotalServiceInstances	Total instances of this mode across all servers — must be identical on every instance of the mode	1, 2, …

Example — two Timer instances across two servers:

Server A  Timer-1\NITROWorkflowService.exe.config
  <add key="ServiceMode"           value="Timer" />
  <add key="ServiceInstanceId"     value="1" />
  <add key="TotalServiceInstances" value="2" />

Server B  Timer-2\NITROWorkflowService.exe.config
  <add key="ServiceMode"           value="Timer" />
  <add key="ServiceInstanceId"     value="2" />
  <add key="TotalServiceInstances" value="2" />

Settings that should match across all instances of the same mode:

Key	Default	Notes
ScheduledSlotIntervalMinutes	5	Timer/Scheduled only. Must divide evenly into 30 and match across instances of the mode.
ScheduledWorkerThreads	4	Timer/Scheduled only. May differ per server by CPU count.
AsyncTickIntervalMinutes	2	Async only. Match across all Async instances.
SiteListCacheMinutes	15	How long the eligible-site list is cached.
SkipIfTimerJobExists	true	Set false only once SP timer jobs are fully deactivated.

Other useful keys: WarmUpDelaySeconds (45), WarmUpRetrySeconds (60), TimerJobCacheHours (24), LogDirectory (logs), LogMaxSizeMB (50), LogRetentionDays (30), DataDirectory (data).

Install the services (elevated command prompt)

Step 1 — create each service (note the required space after binPath=):

sc create "NITROWorkflow-Timer-1"     binPath= "C:\NITROServices\Timer-1\NITROWorkflowService.exe"     start= auto DisplayName= "NITRO Workflow Timer Service 1"
sc create "NITROWorkflow-Scheduled-1" binPath= "C:\NITROServices\Scheduled-1\NITROWorkflowService.exe" start= auto DisplayName= "NITRO Workflow Scheduled Service 1"
sc create "NITROWorkflow-Async-1"     binPath= "C:\NITROServices\Async-1\NITROWorkflowService.exe"     start= auto DisplayName= "NITRO Workflow Async Service 1"

Step 2 — set the service account (use your SPTimerV4 account to avoid extra grants):

sc config "NITROWorkflow-Timer-1"     obj= "DOMAIN\svc-nitro" password= "password"
sc config "NITROWorkflow-Scheduled-1" obj= "DOMAIN\svc-nitro" password= "password"
sc config "NITROWorkflow-Async-1"     obj= "DOMAIN\svc-nitro" password= "password"

Step 3 — configure automatic recovery (restart after 1, 2, then 5 minutes; reset after 24h):

sc failure "NITROWorkflow-Timer-1"     reset= 86400 actions= restart/60000/restart/120000/restart/300000
sc failure "NITROWorkflow-Scheduled-1" reset= 86400 actions= restart/60000/restart/120000/restart/300000
sc failure "NITROWorkflow-Async-1"     reset= 86400 actions= restart/60000/restart/120000/restart/300000

Step 4 — start the services:

sc start "NITROWorkflow-Timer-1"
sc start "NITROWorkflow-Scheduled-1"
sc start "NITROWorkflow-Async-1"

Verify

• sc query “NITROWorkflow-Timer-1” should report STATE: 4 RUNNING.
• Check the log in the instance’s logs\ subfolder (e.g. nitro-timer-1-YYYYMMDD.log). ~45 seconds after start it logs the warm-up, the instance configuration, and a SharedHash.
• Compare SharedHash across all instances of the same mode. If the hashes differ, TotalServiceInstances or the slot interval are inconsistent — stop and fix the configs before proceeding.
• If a service fails to start, check Event Viewer → Windows Logs → Application, source NITROWorkflowService.

Coexistence during migration

With SkipIfTimerJobExists = true (default), a service skips any site that still has an active NITRO timer job, allowing gradual migration: deploy and start the services, disable the SharePoint timer jobs for the sites the services should take over, and once all NITRO timer jobs are disabled set SkipIfTimerJobExists = false and restart the services.

Upgrade the services (new version)

1. sc stop “NITROWorkflow-Timer-1”
2. Copy the new .exe and .dll files into the instance folder — do not overwrite NITROWorkflowService.exe.config (you would lose your configuration).
3. If the release adds new config keys, add them manually per instance (see release notes).
4. sc start “NITROWorkflow-Timer-1”

Uninstall

sc stop   "NITROWorkflow-Timer-1"
sc delete "NITROWorkflow-Timer-1"
(repeat for Scheduled-1 and Async-1)

Always sc stop and confirm STOPPED before sc delete.

Troubleshooting

Symptom	Likely cause	Fix
Service starts then immediately stops	Config validation failed	Check Event Log → Application for the error
No log file appears	Wrong LogDirectory or no write permission	Give the service account write access to the instance folder
Warm-up retrying every 60s	SharePoint unavailable or account lacks SP access	Confirm SP is running; verify the account is a Farm Admin
SharedHash differs across instances	TotalServiceInstances / slot interval mismatch	Correct the mismatched value and restart services
Same sites processed twice	Two instances share a ServiceInstanceId	Assign unique IDs; restart services
Eligible site count is 0	No site has NITRO active, or SP connectivity problem	Verify NITRO is active on at least one site collection

C5. Reverting to timer jobs

To move back from Windows Services to timer jobs: on Manage NITRO Services → NITRO Service tab, remove/stop the services and set the farm option back to NITRO SharePoint Timer Service; then on the SP Timer tab run Verify Timer Jobs to recreate the timer jobs on all NITRO-installed site collections (Part B, Step 4).

Part D — Post-upgrade verification checklist

Area	What to check
Solutions	Deployment Summary shows Success for NITRO Studio, Workflow Manager, and Common Utilities; Get Status confirms the deployed solutions and the active site-collection feature. On multi-server farms, confirm NITRO works on each server.
Site feature	The NITRO buttons appear under the site’s gear (Settings) icon on activated site collections.
Workflow events	Verify Events completed with a success summary and no per-site errors.
Logs	A “NITRO Logs” subsite exists and new workflow runs write log entries there; old log lists optionally cleaned from Site Contents.
Timer jobs	Check Timer Jobs shows the expected NITRO jobs enabled on each NITRO site collection.
Package (if used)	Saved Package Info shows the intended scope/location; repaired/updated site collections load NITRO scripts/CSS from the shared location.
Services (only if adopted — Part C)	All three modes report RUNNING; SharedHash matches across instances of each mode; logs show sites being processed.

Logs. The setup tool writes dated log files under its own Logs folder; each management screen also streams its actions into the on-screen log pane. Keep the deploy log from Step 1 in case you need to review the changeover.

Appendix — Full details of the solution and feature changes

This section is a reference for administrators who want the exact breakdown of what changed in each solution (WSP) and its features. It is not required to perform the upgrade — the required steps are in Part B — but it explains precisely why the upgrade behaves the way it does.

Solution and feature comparison

	Old solution	New solution
CrowCanyon.CommonUtils.wsp
Deployment scope	Global (farm-wide)	Global (farm-wide)
Features	Crow Canyon Mail Templates Administration Custom Action: “Crow Canyon Mail Templates” (Location: Microsoft.SharePoint.SiteSettings) On feature activate: Create CCSCommonMailTemplates list Create CCSDocuSignRequests list Creates DocuSign timer job: “Crow Canyon DocuSign Job For ” + <SiteCollectionURL>	Crow Canyon Mail Templates Administration Not activated — feature has no components (Custom Action and event receiver removed; feature definition remains but is empty).
CrowCanyon.WorkflowManager.wsp
Deployment scope	Web application (deployed only to selected web apps)	Global (farm-wide)
Features	Crow Canyon Workflow Manager Custom Action: “Crow Canyon Workflow Manager” (Location: Microsoft.SharePoint.StandardMenu) Event Receiver file: Event receivers for all lists (Add / Update / Delete) On feature activate: Creates CCSWorkflowManagerSettings list Creates CCSCommonMailTemplates list Creates Workflow Timer job: “CrowCanyon Workflow Manager Job For ” + <SiteCollectionURL> Creates Workflow Async job: “Crow Canyon Workflow Manager Async Job For ” + <SiteCollectionURL> ListTemplateId = “100”	Crow Canyon Workflow Manager Not activated — feature has no components (Custom Action, event receivers, and list/timer-job creation logic all removed; feature definition remains but is empty).
CrowCanyon.NITROStudio.wsp
Deployment scope	Global (farm-wide)	Global (farm-wide)
Features	Crow Canyon NITRO Studio Feature Custom Actions: “Crow Canyon NITRO Studio” (Loc: Microsoft.SharePoint.StandardMenu) “Crow Canyon NITRO Studio” (Loc: Microsoft.SharePoint.SiteSettings) “Crow Canyon NITRO Portal” (Loc: Microsoft.SharePoint.StandardMenu) “Crow Canyon NITRO Portal” (Loc: Microsoft.SharePoint.SiteSettings)	Crow Canyon NITRO Studio Feature Same four Custom Actions as before, plus: “Crow Canyon Workflow Manager” (Loc: Microsoft.SharePoint.StandardMenu) — now consolidated into this single feature.

Summary of the change

Aspect	Old model	New model
Active feature (with components)	3 (one per WSP)	1 (Crow Canyon NITRO Studio Feature only)
Mail Templates / Workflow Manager features	Fully functional, with Custom Actions and Event Receivers	Still exist as feature definitions but have no components — effectively inert, do not activate anything
Workflow Manager WSP scope	Web-application level	Farm-wide (global)
List creation	Done automatically via OnActivate event receivers on feature activation	Done via Apply NITRO Settings in the NITRO Helper setup tool
Timer job creation	Done automatically via OnActivate event receivers	Done via Manage NITRO Services (Timer) form in the setup tool
Workflow event wiring	Baked into Workflow Manager’s OnActivate / event-receiver file	Done via Manage Workflow Events form in the setup tool for one-time upgrade. Done via the NITRO Workflows page when saving workflows.
UI entry point	Spread across three separate features’ Custom Actions	Consolidated into the single NITRO Studio feature’s Custom Actions

Net effect: after upgrading, only the NITRO Studio Feature is ever activated at the site-collection level. Everything the retired Mail Template and Workflow Manager features used to do on activation — creating lists, creating timer jobs, and wiring workflow events — is now done explicitly through this setup tool (see Steps 1-4 in Part B).