Merge pull request #131 from netwrix/ssk/pgsalesforce-notes

Fixed Tables, Notes, Tips, Block Quotes and subheadings.

Author: shannon-kelley-netwrix

docs/platgovsalesforce/changemanagement/change_and_approval_policy.md

@@ -25,13 +25,13 @@ process are analyzed against the policy for compliance.
 
 For example, a company may have multiple policies:
 
-1. A **Default Policy** that applies to any customization or process without a specific policy. This
+1. **Default Policy** that applies to any customization or process without a specific policy. This
    generally requires that scripted changes go through a relatively high level of review compared to
    non-scripted changes.
-2. A **Controls Policy** that specifically applies to key reports and controls listed on the policy
+2. **Controls Policy** that specifically applies to key reports and controls listed on the policy
    that need very specific approval to modify and ensures there are no changes without a proper
    audit review.
-3. A **Custom Object Policy** to manage Custom fields and object.
+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

docs/platgovsalesforce/changemanagement/change_management_overview.md

@@ -42,9 +42,11 @@ The **Advanced Change Management** Module provides additional functionality:
 - Archive fields.
 - Delete customizations.
 
+:::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.
+:::
 
 ### Confirm with a Deployment Record
 

docs/platgovsalesforce/changemanagement/change_management_reports.md

@@ -18,33 +18,14 @@ To access the Change Reports:
 
 Open **Netwrix Dashboard** > **Reports** > **Change Enablement** and select one of the reports:
 
-> **Approval Override**: shows all changes approved with an approval override.
->
-> **What Changed?**: shows all changes that have occurred.
->
-> **Unresolved Non-Compliant Changes**: displays open non-compliant changes. A non-compliant change
-> indicates something was changed without the required approvals. By looking at this report, you can
-> investigate changes and get an understanding of what the impacts are and see if any additional
-> changes need to be made. This report is used to track changes that require action.
->
-> **Managed Package Updates**: displays managed package update details for auditing.
->
-> **Resolved Non-Compliant Changes**: displays resolved non-compliant changes with the change
-> overview and the difference summary.
->
-> **Compliant Changes**: displays all compliant changes. Compliant changes are automatically marked
-> as closed. This report is used to review changes that have been automatically cleared.
->
-> **Consolidated Change By Type**: displays changes summarized and grouped by Salesforce Type.
->
-> **Deployed Changes**: displays an end to end summary of deployed changes to enable tracking and
-> reporting of changes to the system.
->
-> **Data Tracking Change Logs**: displays changes on objects set for data tracking.
->
-> **Change/Approval Policy Changes**: this report is based on Field History Tracking. You can track
-> up to 20 fields from the Policy Record. Salesforce starts tracking field history from the date and
-> time you turn it on a field.
->
-> **Fast Scan for Permissions Changes**: displays all changes detected in PermissionSet,
-> PermissionSetGroup, and Profiles by the Fast Scan.
+- **Approval Override**: shows all changes approved with an approval override.
+- **What Changed?**: shows all changes that have occurred.
+- **Unresolved Non-Compliant Changes**: displays open non-compliant changes. A non-compliant change indicates something was changed without the required approvals. By looking at this report, you can investigate changes and get an understanding of what the impacts are and see if any additional changes need to be made. This report is used to track changes that require action.
+- **Managed Package Updates**: displays managed package update details for auditing.
+- **Resolved Non-Compliant Changes**: displays resolved non-compliant changes with the change overview and the difference summary.
+- **Compliant Changes**: displays all compliant changes. Compliant changes are automatically marked as closed. This report is used to review changes that have been automatically cleared.
+- **Consolidated Change By Type**: displays changes summarized and grouped by Salesforce Type.
+- **Deployed Changes**: displays an end to end summary of deployed changes to enable tracking and reporting of changes to the system.
+- **Data Tracking Change Logs**: displays changes on objects set for data tracking.
+- **Change/Approval Policy Changes**: this report is based on Field History Tracking. You can track up to 20 fields from the Policy Record. Salesforce starts tracking field history from the date and time you turn it on a field.
+- **Fast Scan for Permissions Changes**: displays all changes detected in PermissionSet, PermissionSetGroup, and Profiles by the Fast Scan.

docs/platgovsalesforce/changemanagement/creating_change_request.md

@@ -14,7 +14,9 @@ types of Change Requests to match the change you want to manage. Here are two op
 - **Data Record** - Change request is used for Data Changes to Revenue Cloud/
   [CPQ](/docs/platgovsalesforce/changemanagement/enhanced_cpq_support.md).
 
+:::note
 Data Record Change Requests are only available with an Enterprise Compliance license.
+:::
 
 1. Open the **Change Requests** tab.
 2. Click **New**
@@ -147,8 +149,11 @@ add additional approvers, approver notes and begin the approval process.
 5. Click **Submit for Approval** to start the process. Approval notifications are sent to the
    approvers.
 
+:::note
 If you created the Change Request in your sandbox to determine the scope of the change, recreate it
-in your Production environment to enable approvals and ongoing tracking.  
+in your Production environment to enable approvals and ongoing tracking.
+:::
+
 For new objects that do not yet exist in Production, edit the Change Request and enter the full API
 Names of these objects into the Proposed Customization fields in the Scope Section. You can add
 multiple API Names by using the Add button. Save the Change Request when complete.

docs/platgovsalesforce/changemanagement/documented_metadata_types.md

@@ -6,7 +6,7 @@ sidebar_position: 110
 
 # Documented Metadata Types
 
-You can view the documented Metadata by Type or by Category.
+You can view the documented Metadata by [Type](#metadata-by-type) or by [Category](#metadata-by-category).
 
 ## Metadata by Type
 

docs/platgovsalesforce/changemanagement/set_up_data_tracking.md

@@ -10,8 +10,10 @@ Data tracking is used for Salesforce CPQ and any sensitive data fields you want
 data tracking enables Platform Governance for Salesforce to track data and create change logs for
 any data changes.
 
+:::note
 If you track an object, all changes to the object and fields are tracked. Consult with your security
 and audit teams to develop a list of objects before enabling data tracking.
+:::
 
 ## Prerequisites
 

docs/platgovsalesforce/changemanagement/setting_up_policies.md

@@ -17,46 +17,26 @@ You can create a New Policy, or edit an existing one:
 
 ## Details
 
-> Information general information about the policy.
->
-> Code and Data Model Changes change control level for code and data model changes.
->
-> Automation Changes change control level for approval process, business process, flow, workflow and
-> process builder changes.
->
-> Sharing and Visibility Changes change control level for role, profile, permission set, data
-> security, sharing non material and indirect changes to profile changes.
->
-> Integration Changes change control level for external site, identity, and access changes.
->
-> Configuration Changes change control level for data quality and general settings changes.
->
-> Display and UI Changes change control level for application, label and translation, layout and
-> template changes.
->
-> Analytics Changes change control level for reports, dashboards, list view, and Einstein changes.
->
-> Control Changes change control level for control changes.
->
-> Application Configuration Changes (Data)
->
-> Health Check Changes change control level for health check changes.
->
-> IT Policies preliminary and final approvers.
->
-> Customization Policies impacted customization approval.
->
-> Management Policies executive approver and approval settings.
->
-> Change Enablement Defaults merge approval list, non conforming alerts, and sequential approval
-> requests.
->
-> **System Information**, **Created By** and **Last Modified By** dates. Informational only, cannot
-> be edited.
+- **Information** general information about the policy.
+- **Code and Data Model Changes** change control level for code and data model changes.
+- **Automation Changes** change control level for approval process, business process, flow, workflow and process builder changes.
+- **Sharing and Visibility Changes** change control level for role, profile, permission set, data security, sharing non material and indirect changes to profile changes.
+- **Integration Changes** change control level for external site, identity, and access changes.
+- **Configuration Changes** change control level for data quality and general settings changes.
+- **Display and UI Changes** change control level for application, label and translation, layout and template changes.
+- **Analytics Changes** change control level for reports, dashboards, list view, and Einstein changes.
+- **Control Changes** change control level for control changes.
+- **Application Configuration Changes (Data)**
+- **Health Check Changes** change control level for health check changes.
+- **IT Policies** preliminary and final approvers.
+- **Customization Policies** impacted customization approval.
+- **Management Policies** executive approver and approval settings.
+- **Change Enablement Defaults** merge approval list, non conforming alerts, and sequential approval requests.
+- **System Information**, **Created By** and **Last Modified By** dates. Informational only, cannot be edited.
 
 Once the policy is saved, **System Information** is added show the **Created By** and **Last
 Modified By** user and time stamp. The information you entered on the form is shown on the
-**Details** tab. The Related tab is now available to add Customizations and view additional
+**Details** tab. The Related tab is available to add Customizations and view additional
 information and history.
 
 ### Information
@@ -72,10 +52,10 @@ Set the required Change Level for each Metadata Type. The Default is shown in th
 
 | **Change Level**                        | **Description**                                                                                                                                                                         |
 | --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| **Log Changes Only**                    | Since the system automatically logs all changes, this change level requires no actions for compliance. Any changes to these objects are automatically marked compliant.                 |
-| **Change Request**                      | Any changes to these objects require an Approved Change Request.                                                                                                                        |
-| **Sandbox Development & Testing**       | Any changes to these objects require an Approved Change Request in the Stage Development Project. It also requires that a parent Change Request is attached to the Development Project. |
-| **Full Software Development Lifecycle** | Any changes to these objects require an Approved Change Request.                                                                                                                        |
+| Log Changes Only                    | Since the system automatically logs all changes, this change level requires no actions for compliance. Any changes to these objects are automatically marked compliant.                 |
+| Change Request                      | Any changes to these objects require an Approved Change Request.                                                                                                                        |
+| Sandbox Development & Testing       | Any changes to these objects require an Approved Change Request in the Stage Development Project. It also requires that a parent Change Request is attached to the Development Project. |
+| Full Software Development Lifecycle | Any changes to these objects require an Approved Change Request.                                                                                                                        |
 
 ### Code and Data Model Changes
 

docs/platgovsalesforce/changemanagement/using_change_logs.md

@@ -27,60 +27,31 @@ Here is an example change log for a **Profile** Metadata type.
 
 ## Details Tab
 
-> **Actual Change Date**: Date the Customization was last modified.
->
-> **Customization Created By**: User who created the customization.
->
-> **Customization Modified By**: User who last modified the customization.
->
-> **Customization**: Linked Customization(s) that have changed.
->
-> **Metadata Type**: Salesforce metatdata type of the Customization.
->
-> **Field Name**: Name of the changed field.
->
-> **Active**: Checked if the Customization is active.
->
-> **New Customization**: Checked if new customization.
->
-> **Package**: Name of the Managed Package if the customizations belong to a managed package.
->
-> **Operation**: Flag this field if a change or a new record is created.
->
-> **Change Overview**: Overview of the change.
->
-> **Data Record Id**: ID of the data record changed. This field is not in all Metadata Types.
->
-> **Data Record Name**: Name of the data record changed. This field is not in all Metadata Types.
->
-> **Data Record SObject API**: API name of the parent SObject of the data record changed. This field
-> is not in all Metadata Types.
->
-> **Related Change Request**: Change request related to the change or used to perform regression
-> analysis of a non-compliant change.
->
-> **Compliant Indicator**: Green flag indicates compliant, red flag indicates non-compliant.
->
-> **Non-Compliant**: Checked if the change is non-compliant.
->
-> **Compliance**: The change status: **Compliant** or **Non-compliant**.
->
-> **Policy**: Policies associated with the Change Log.
->
-> **Reason**: Name of the policy violated by the change.
->
-> **Filters**: List of filters satisfied for the data record change. If blank, no filters specified.
-> This field is not in all Metadata Types.
->
-> **Parent Change Log**: Name of the parent change log if applicable.
->
-> **Resolution Description**: Description of any steps taken to bring the change back into
-> compliance. This field is not in all Metadata Types.
->
-> **Short Resolution Description**: Summary description of any steps taken to bring the change back
-> into compliance.
->
-> **Status**: Current state of the Change Log. This field is manually set.
+- **Actual Change Date**: Date the Customization was last modified.
+- **Customization Created By**: User who created the customization.
+- **Customization Modified By**: User who last modified the customization.
+- **Customization**: Linked Customization(s) that have changed.
+- **Metadata Type**: Salesforce metadata type of the Customization.
+- **Field Name**: Name of the changed field.
+- **Active**: Checked if the Customization is active.
+- **New Customization**: Checked if new customization.
+- **Package**: Name of the Managed Package if the customizations belong to a managed package.
+- **Operation**: Flag this field if a change or a new record is created.
+- **Change Overview**: Overview of the change.
+- **Data Record Id**: ID of the data record changed. This field is not in all Metadata Types.
+- **Data Record Name**: Name of the data record changed. This field is not in all Metadata Types.
+- **Data Record SObject API**: API name of the parent SObject of the data record changed. This field is not in all Metadata Types.
+- **Related Change Request**: Change request related to the change or used to perform regression analysis of a non-compliant change.
+- **Compliant Indicator**: Green flag indicates compliant, red flag indicates non-compliant.
+- **Non-Compliant**: Checked if the change is non-compliant.
+- **Compliance**: The change status: **Compliant** or **Non-compliant**.
+- **Policy**: Policies associated with the Change Log.
+- **Reason**: Name of the policy violated by the change.
+- **Filters**: List of filters satisfied for the data record change. If blank, no filters specified. This field is not in all Metadata Types.
+- **Parent Change Log**: Name of the parent change log if applicable.
+- **Resolution Description**: Description of any steps taken to bring the change back into compliance. This field is not in all Metadata Types.
+- **Short Resolution Description**: Summary description of any steps taken to bring the change back into compliance.
+- **Status**: Current state of the Change Log. This field is manually set.
 
 ### Diff Summary
 
@@ -107,21 +78,14 @@ The **Created By** and **Last Modified By** users and dates are displayed at the
 The **Audit** section displays all fields related to an audit. Click the edit icon to edit the
 record.
 
-> **Sampled For Audit**: Select **None**, **Internal** or **External**.
->
-> **Audited By**: Auditor selects their user name from the list.
->
-> **Internal Audit Comments**: Internal notes added by the Auditor.
->
-> **Internal Audit Status**: Select **None**, **Approved**, **Rejected** or **Under Investigation**.
->
-> **Last Internal Audit**: User who made the last change in the Internal Audit fields.
->
-> **External Audit Comments**: External notes added by the Auditor.
->
-> **External Audit Status**: Select **None**, **Approved**, **Rejected** or **Under Investigation**.
->
-> **Last External Audit**: User who made the last change in the External Audit fields.
+- **Sampled For Audit**: Select **None**, **Internal** or **External**.
+- **Audited By**: Auditor selects their user name from the list.
+- **Internal Audit Comments**: Internal notes added by the Auditor.
+- **Internal Audit Status**: Select **None**, **Approved**, **Rejected** or **Under Investigation**.
+- **Last Internal Audit**: User who made the last change in the Internal Audit fields.
+- **External Audit Comments**: External notes added by the Auditor.
+- **External Audit Status**: Select **None**, **Approved**, **Rejected** or **Under Investigation**.
+- **Last External Audit**: User who made the last change in the External Audit fields.
 
 ## Related Tab
 

docs/platgovsalesforce/cleanup/cleanup_customizations.md

@@ -53,9 +53,9 @@ Use these processes to Clean up Individual Customization or Clean Up Multiple Cu
 
 6. Restrict Visibility. You can choose to have the list view:
 
-- Only visible to you,
-- Visible to all users or
-- Visible to certain groups of users.
+    - Only visible to you,
+    - Visible to all users or
+    - Visible to certain groups of users.
 
 7. Click **Save**.
 8. Once your list view has been created, you can multi-select customizations for clean up by

docs/platgovsalesforce/cleanup/cleanup_overview.md

@@ -10,8 +10,8 @@ Clean up involves some or all of the following steps:
 
 1. Identify and remove unused customizations (either individual or multiple):
 
-- Completely unused
-- Useless or inefficient
+    - Completely unused
+    - Useless or inefficient
 
 2. Identify and fix improperly set-up customizations (eg. no help text, inactive owner).
 3. Describe each object and its clean up task (under the improvements tab.)
@@ -29,8 +29,10 @@ same steps:
 4. Manage the clean up as appropriate
 5. Run the scanner
 
+:::note
 Always check the Last Date Scanned on any object and re-scan that object if necessary to ensure the
 information about that object is up to date.
+:::
 
 ### Select the Approach
 
@@ -55,9 +57,11 @@ Strongpoint homepage under Strongpoint Features and Reports.
 You can clean up individual or multiple customizations by going to the Customization tab and
 selecting **Create New View**. Use the filters to generate your list.
 
+:::note
 Before moving on to other clean up activities, it is often a good idea to delete unused
 customizations that are highly likely safe to delete, such as fields that have not been used in
 years or that are not used by any other customization.
+:::
 
 ### Analyze and Organize the Results