dev to main

docs/platgovnetsuite/CLAUDE.md

@@ -0,0 +1,76 @@
+# CLAUDE.md
+
+This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
+
+## Product
+
+**Platform Governance for NetSuite** (formerly Strongpoint) is a NetSuite SuiteApp that auto-documents customizations and enforces change management and compliance workflows. It is a single-version SaaS product (`version: "current"`), so all edits apply to the one live version.
+
+The legacy product name "Strongpoint" still appears in some file names, internal NetSuite UI labels, and older content. When writing or editing docs, use "Platform Governance for NetSuite" — not "Strongpoint" — except when referring to a specific UI element that says "Strongpoint" (e.g., the Strongpoint tab in NetSuite's toolbar).
+
+## Content Map
+
+| Directory | What it covers |
+|---|---|
+| `installation/` | Bundle install, Spider setup, user/role/permission management, license types |
+| `changemanagement/` | Change Requests, Process Issues, Deployment Records, Opportunistic Clearance, environment comparison, approval policies |
+| `customization/` | Customization records, impact analysis, ERD, change logs |
+| `cleanup/` | Archiving, restoring, and deleting unused fields and customizations |
+| `scriptmgmt/` | Critical Script Analysis: performance, errors, debugging logs, scheduler |
+| `sod/` | Advanced Segregation of Duties: rules, violations, approvals, reports, clean-up |
+| `uar/` | User Access Review: role/permission/membership reviews, admin/owner/auditor/additional-reviewer roles |
+| `agent/` | Automated IT/financial controls, control incidents, lookback, pre-approved changes |
+| `ticketingintegrations/` | Jira (classic + Forge), ServiceNow, Zendesk integrations; REST API overview (Change Request API, Customizations API) |
+| `tools/` | Spider, Standard Field Impact Analysis |
+| `automatedsearchcleanup/` | Automated cleanup of unused saved searches |
+| `bundleremoval/` | Uninstalling the bundle |
+| `integrations/` | Integration mapping between NetSuite and external systems |
+| `reportabug/` | Troubleshooting guides for known issues |
+| `archive/` | Release notes for versions 7.0–7.3 |
+
+## Key Terminology
+
+- **Spider** — the scanning process that catalogs all NetSuite customizations; runs on a schedule or manually. Takes 4–5 days on first run.
+- **Customization Record** — a Platform Governance record that documents a single NetSuite customization object (script, field, workflow, etc.)
+- **Change Request** — the central record for planning, approving, and tracking a change. Links to Process Issues, Deployment Records, and customizations.
+- **Process Issue** — optional pre-change record for triaging and initiating a Change Request; can link to external ticketing systems.
+- **Deployment Record** — tracks deployment approvals after a Change Request is approved.
+- **Agent** — the automated control engine; monitors financially relevant records and fields outside of configuration changes.
+- **SoD (Segregation of Duties)** — role/permission conflict detection and enforcement.
+- **UAR (User Access Review)** — periodic review process confirming users have appropriate roles and permissions.
+- **Opportunistic Clearance** — a setting that auto-clears low-risk non-compliant changes without full approval.
+- **Change Level** — the compliance tier required for a change, determined automatically by change/approval policies.
+
+## Module Tiers
+
+Content frequently references which license tier a feature requires. The three tiers are:
+
+1. **Documentation** — Spider + Customization Records
+2. **Intelligent Change Management** — adds Change Requests, Process Issues, environment comparison
+3. **Enterprise Compliance** — adds Advanced SoD, UAR, Agent, blocking controls
+
+When editing features gated behind a tier, check `installation/features_by_license_type.md` for the current mapping before making claims about availability.
+
+## UAR Role Structure
+
+UAR has four distinct reviewer roles, each with its own subdirectory under `uar/`:
+
+- **Admin** (`adminoverview/`) — creates and manages reviews
+- **Owner** (`owneroverview/`) — reviews roles they own
+- **Auditor** (`auditoroverview/`) — read-only audit access
+- **Additional Reviewer** (`addrevieweroverview/`) — assigned by Owners for membership reviews
+
+When editing UAR content, verify which role perspective the file is written from — they have overlapping but distinct workflows.
+
+## Ticketing Integrations
+
+There are two separate Jira integrations:
+
+- **Jira Integration** (`jiraintegration/`) — older REST-based integration
+- **Jira Forge Integration** (`jiraforgeintegration/`) — newer Forge app-based integration
+
+These are distinct products with different setup steps. Don't conflate them.
+
+## Images
+
+Images are stored at `/static/images/platgovnetsuite/` organized by section (e.g., `/images/platgovnetsuite/sod/`, `/images/platgovnetsuite/uar/`). Reference with absolute paths. Image format is `.webp`.

docs/platgovsalesforce/CLAUDE.md

@@ -0,0 +1,71 @@
+# CLAUDE.md
+
+This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
+
+## Product
+
+**Platform Governance for Salesforce** (formerly Strongpoint) is a Salesforce managed package that auto-documents customizations and enforces change management and compliance workflows. It is a single-version SaaS product (`version: "current"`), so all edits apply to the one live version.
+
+The legacy product name "Strongpoint" still appears in some directory names (`installingstrongpoint/`), internal Salesforce UI labels (e.g., "Strongpoint DLU Parameter", "Strongpoint Home Page"), and older content. When writing or editing docs, use "Platform Governance for Salesforce" — not "Strongpoint" — except when referring to a specific UI element that literally says "Strongpoint."
+
+The app is accessed in Salesforce via **App Launcher > Netwrix Lightning**.
+
+## Content Map
+
+| Directory | What it covers |
+|---|---|
+| `installingstrongpoint/` | Package install, authentication (Named Credentials / Session ID), Getting Started Wizard, scanner setup, permission sets, sandbox setup, license types |
+| `changemanagement/` | Change Requests, change/approval policies, change logs, data tracking, documented metadata types, resolving non-compliant changes |
+| `cleanup/` | Cleanup overview, unused customization tools, Date Last Used (DLU) |
+| `customizations/` | Customization records (Lightning and legacy), folder customizations |
+| `releasemanagement/` | Deployments, deployment logs, multiple environments, rollback |
+| `integrations/` | Jira (classic and Forge), Zendesk integrations |
+| `reports/` | Deployment log report pages |
+| `scanner/` | Scanner overview, running, scheduling, FastScan, field-level scanner, DLU scanner, troubleshooting |
+| `settings/` | Settings overview, credentials |
+| `techdebt/` | Tech debt workflows: auto-documentation, change monitoring, org clean-up, org-specific approaches |
+| `tools/` | Access review, DRD, environment comparison, field tracking, package usage, profile/permission comparison, system permission tracking, user activity, export tools |
+| `release_7_0/` | Release notes for the current release |
+
+## Key Terminology
+
+- **Scanner** — the process that catalogs all Salesforce metadata customizations; replaces the term "Spider" used in Platform Governance for NetSuite. Takes 4–5 days on first run.
+- **Customization Record** — a Platform Governance record documenting a single Salesforce metadata object (field, class, flow, etc.).
+- **Change Request** — the central record for planning, approving, and tracking a change.
+- **Change Log** — audit trail of changes to customizations; generated automatically by the scanner.
+- **DRD (Dependency Relationship Diagram)** — graphical view of a customization and its relationships with other objects.
+- **DLU (Date Last Used)** — tracks when a customization was last actively used; used to identify candidates for cleanup.
+- **Platform Governor** — monitors Salesforce Governor Limit usage.
+- **FastScan** — a targeted quick scan for specific metadata types.
+- **Change/Approval Policy** — rules that define what level of approval a change to a given customization requires.
+- **Data Tracking** — optional feature that logs or blocks changes to data records (not just metadata).
+
+## License Tiers
+
+Content frequently references which license tier a feature requires. The three tiers are:
+
+1. **Automated Documentation** — Scanner, Customization Records, DRD, Cleanup, Profile/Permission Comparison
+2. **Intelligent Change Enablement** — adds Change Requests, deployments, environment comparison, user activity
+3. **Enterprise Compliance** — adds Financial Controls, audit reports
+
+When editing features gated behind a tier, check `installingstrongpoint/features_by_license_type.md` for the current mapping.
+
+## Authentication Methods
+
+There are two authentication methods. Understanding both matters for the install and credentials docs:
+
+- **Named Credentials (OAuth)** — recommended for all orgs; required when Salesforce user profiles have High Assurance enabled. Configured via External Client App. Does not break on session expiry.
+- **Session ID (legacy)** — uses a dedicated Integration User's username, password, and security token. Does not work with High Assurance. Documented inside a `<details>` block in `installingstrongpoint/installing_strongpoint.md`.
+
+## Ticketing Integrations
+
+There are two separate Jira integrations:
+
+- **Jira Integration** (`integrations/jiraintegration/`) — older REST-based integration
+- **Jira Forge Integration** (`integrations/jiraintegrationForge/`) — newer Forge app-based integration
+
+These are distinct products with different setup steps. Don't conflate them.
+
+## Images
+
+Images are stored at `/static/images/platgovsalesforce/` organized by section (e.g., `/images/platgovsalesforce/installingstrongpoint/`, `/images/platgovsalesforce/customizations/`). Reference with absolute paths. Image format is `.webp`.

docs/platgovsalesforce/changemanagement/approving_change_request.md

@@ -6,20 +6,20 @@ sidebar_position: 50
 
 # Approving a Change Request
 
-Approvers are populated from the Change/Approval Policy for the Change Request. Approval
-notifications are sent when the Change Request owner advances the status to **Pending Approval**.
+The Change/Approval Policy determines the approvers for the Change Request. The system sends
+approval notifications when the Change Request owner advances the status to **Pending Approval**.
 
 1. Approvers receive an email with a link to the Change Request.
 2. When the Change Request opens, **Approve** and **Reject** buttons are available at the top of the
    form:
 
-    - If an approver rejects the Change Request, the status is changed to **Rejected**. You can
+    - If an approver rejects the Change Request, the status changes to **Rejected**. You can
       return the Change Request to **In Progress**, edit it, and re-submit it for approval if
       there are errors or omissions.
 
 3. Change Request owner [Completes and Validates the Change Request](/docs/platgovsalesforce/changemanagement/completing_change_request.md).
 
-Once the Change Request is approved, you cannot change the customizations associated with it or make any other modifications to the record.
+After the Change Request is approved, you can't change the customizations associated with it or make any other modifications to the record.
 
 You can add the **Netwrix CR Approval Override** Permission Set to specific users. Users with
 this Permission Set can approve a Change Request independently of the governing policy. 

docs/platgovsalesforce/changemanagement/change_and_approval_policy.md

@@ -20,7 +20,7 @@ customizations and processes. It identifies the Change Policy that applies based
 the Customization Record and the process risk from the Process Records.
 
 The Change and Approval Policy also determines the change level required for any detected changes to
-be compliant. This ensures that even changes that do not go through the planned change management
+be compliant. This ensures that even changes that don't go through the planned change management
 process are analyzed against the policy for compliance.
 
 For example, a company may have multiple policies:
@@ -33,18 +33,18 @@ For example, a company may have multiple policies:
    audit review.
 3. **Custom Object Policy** to manage Custom fields and object.
 
-Once in place, policies remind users of the level of change management required as well as monitors
-the changes that do occur and raises alerts to IT by custom reports if there are any change
+After policies are in place, they remind users of the level of change management required and monitor
+the changes that occur, raising alerts to IT through custom reports if there are any change
 violations.
 
 ## Change Process Overview
 
 Platform Governance for Salesforce automatically detects any changes to the customizations in your
-system and log them. The system finds the relevant Change/Approval Policy and determines the change
+system and logs them. The system finds the relevant Change/Approval Policy and determines the change
 level required for compliance. It then looks for the relevant change record. For example, if it
 determines that a script changed and a Full Software Development Lifecycle was required for
-compliance, it looks for an approved Deployment Record. If it does not find one, it flags the change
-as non-compliant. An alert is sent to the Object owners notifying them of the non-compliant change.
+compliance, it looks for an approved Deployment Record. If it doesn't find one, it flags the change
+as non-compliant. Platform Governance for Salesforce sends an alert to the Object owners notifying them of the non-compliant change.
 
 1. **Detect the Change**: [Automated Scanner](/docs/platgovsalesforce/installingstrongpoint/setting_up_initial_scan.md)
    must be enabled forPlatform Governance for Salesforce to detect a change.
@@ -56,8 +56,8 @@ as non-compliant. An alert is sent to the Object owners notifying them of the no
     - If Platform Governance for Salesforce finds the appropriate Change Request or if the change is
       **Log Only**, it marks the change as compliant and attaches the Change Log to the Change
       Record.
-    - If Platform Governance for Salesforce determines the change is non-compliant (does not fall
-      under the relevant policy) it send an alert to IT and Object Owners to investigate the change
+    - If Platform Governance for Salesforce determines the change is non-compliant (doesn't fall
+      under the relevant policy) it sends an alert to IT and Object Owners to investigate the change
       and document what needs to be done to make the change compliant.
 
 6. **Change Reporting and Resolution**: Platform Governance for Salesforce provides predefined

docs/platgovsalesforce/changemanagement/change_log_reportfolder_dashboardfolder.md

@@ -21,7 +21,7 @@ The Change Log is organized into two main panels:
 | Package | The package where the change was logged |
 | Related Change Request | Reference to the associated Change Request (if any) |
 | Compliant Indicator | Compliance status according to the active policy |
-| Active | Whether the customization is currently active |
+| Active | Whether the customization is active |
 
 ### 2. "CHANGE DETAILS" Panel
 
@@ -48,7 +48,7 @@ The Change Log is organized into two main panels:
 
 ## Additional Notes
 
-- Access changes are tracked with specific indicators:
+- The system tracks access changes with specific indicators:
   - "Change Type" shows the nature of the modification
   - When access is revoked, "Change Type" displays "Removed"
 - The layout is consistent for both ReportFolder and DashboardFolder

docs/platgovsalesforce/changemanagement/change_management_overview.md

@@ -10,19 +10,19 @@ Platform Governance for Salesforce Closed Loop Change Management and Compliance
 change management system for changes to Salesforce accounts using the Platform Governance for
 Salesforce automated documentation and change management system.
 
-Platform Governance for Salesforce extends your current change management system to enable you to:
+With Platform Governance for Salesforce, you can extend your current change management system to:
 
 - Establish change management policies for different types of objects and processes.
 - Route changes for approval within Salesforce.
 - Authenticate that changes to the system are in accordance with applicable policies.
 - Detect and resolve non-compliant changes.
 - Manage deployments and sandbox refreshing using best practices.
 
-## Plan, Approve and Deploy Changes
+## Plan, Approve, and Deploy Changes
 
 ### Plan with a Change Request
 
-Change Requests are used to plan and track changes to the system.
+Use Change Requests to plan and track changes to the system.
 
 They allow for common actions associated with change requests including:
 
@@ -44,21 +44,21 @@ The **Advanced Change Management** Module provides additional functionality:
 
 :::note
 Change Management can be integrated with other change tracking systems using the External Change
-Request Number field. It is beneficial to use the change records since they can be linked to
-processes, customizations and clean up activities.
+Request Number field. Use the change records because they can be linked to
+processes, customizations, and clean-up activities.
 :::
 
 ### Confirm with a Deployment Record
 
-When tracking Full Software Development Lifecycle changes, the Deployment Record enables you to
-track deployment approvals. Once a Change Request is approved, this documents a change is ready for
-development. At this point, a new change request with the Stage Deployment Record can be created and
-tracked.
+When tracking Full Software Development Lifecycle changes, use the Deployment Record to
+track deployment approvals. Once a Change Request is approved, the Deployment Record documents that
+a change is ready for development. You can then create and track a new change request with the
+Stage Deployment Record.
 
 This enables:
 
 - Tracking of deployment activities.
 - Documentation of approvals for deployment to document that any changes that occurred during
   development have been approved and that the appropriate pre-deployment checks have been completed.
 
-This record is linked to the original change request to enable end to end reporting of the change.
+This record links to the original change request to enable end-to-end reporting of the change.