@raishin/vanguard-frontier-agentic 2.3.0 → 2.5.0

package/skills/salesforce/salesforce-metadata-review-skill/references/deprecated-metadata.md

@@ -0,0 +1,217 @@
+# Deprecated Metadata Reference
+
+Reference for deprecated Salesforce standard objects, end-of-life API versions,
+and legacy automation types that should be migrated or decommissioned.
+
+Deprecation timelines change. Always verify
+current retirement dates with Salesforce official release notes.
+
+---
+
+## Deprecated Automation Types
+
+### Workflow Rules
+
+Workflow Rules are one of Salesforce's original automation tools. Salesforce
+has announced their retirement.
+
+**Current Status:** End-of-life scheduled. No new Workflow Rules can be created
+in new orgs. Existing rules continue to function but Salesforce has announced
+a retirement date.
+Verify retirement date.
+
+**Migration Target:** Record-Triggered Flow (Before-Save or After-Save).
+
+**Detection Query:**
+```sql
+SELECT Id, Name, Active, Description, TableEnumOrId
+FROM WorkflowRule
+WHERE Active = true
+ORDER BY TableEnumOrId, Name
+```
+
+**Migration Guide:**
+1. For each active Workflow Rule, identify its actions:
+   - Field Update -> Before-Save Flow assignment element.
+   - Email Alert -> After-Save Flow Send Email action.
+   - Task -> After-Save Flow Create Records element.
+   - Outbound Message -> After-Save Flow HTTP Callout or Platform Event.
+2. Build equivalent logic in Flow.
+3. Test in sandbox.
+4. Deactivate Workflow Rule and activate Flow.
+
+### Process Builder
+
+Process Builder is a visual automation tool introduced as a Workflow Rule
+replacement. It is now itself being retired in favor of Flow.
+
+**Current Status:** End-of-life scheduled. No new processes can be created
+in new orgs.
+
+**Migration Target:** Record-Triggered Flow.
+
+**Detection Query:**
+```sql
+SELECT Id, ApiName, Label, Status, LastModifiedDate
+FROM FlowDefinition
+WHERE ProcessType = 'Workflow'
+  AND Status = 'Active'
+ORDER BY Label
+```
+Process Builder processes have `ProcessType = 'Workflow'` in the FlowDefinition metadata.
+
+### Legacy Assignment Rules and Auto-Response Rules
+
+Assignment Rules and Auto-Response Rules for Cases and Leads are not deprecated
+but are not enhanced with new capabilities. They remain functional.
+
+**Recommendation:** For complex assignment logic, migrate to Record-Triggered
+Flows which offer more conditional power and better visibility.
+
+---
+
+## End-of-Life API Versions
+
+Salesforce retires old API versions periodically. Apex code, integrations, and
+metadata deployed with retired API versions may stop functioning.
+
+**Retirement Pattern:** Salesforce typically retires API versions that are more
+than ~3 years old. The exact retirement dates are published annually.
+
+### Checking API Versions in Use
+
+```bash
+# Check API versions in Apex classes
+sf data query \
+  --query "SELECT Name, ApiVersion, Status FROM ApexClass WHERE Status = 'Active' ORDER BY ApiVersion ASC LIMIT 200" \
+  --use-tooling-api \
+  -o my-org
+
+# Check API versions in Apex triggers
+sf data query \
+  --query "SELECT Name, ApiVersion, Status FROM ApexTrigger WHERE Status = 'Active' ORDER BY ApiVersion ASC LIMIT 200" \
+  --use-tooling-api \
+  -o my-org
+
+# Check API versions in Flows
+sf data query \
+  --query "SELECT Label, ApiVersion FROM FlowDefinition WHERE Status = 'Active' ORDER BY ApiVersion ASC LIMIT 200" \
+  --use-tooling-api \
+  -o my-org
+```
+
+**Finding:** Any Apex class or trigger on API version < 50.0 should be reviewed
+for update. Versions < 40.0 are likely to be in or near retirement.
+
+### Updating API Version in Metadata
+
+```xml
+<!-- In force-app/main/default/classes/MyClass.cls-meta.xml -->
+<?xml version="1.0" encoding="UTF-8"?>
+<ApexClass xmlns="http://soap.sforce.com/2006/04/metadata">
+    <apiVersion>59.0</apiVersion>  <!-- Update from old version -->
+    <status>Active</status>
+</ApexClass>
+```
+
+After updating the API version, test thoroughly — behavior changes between
+API versions may affect code that relies on specific platform behaviors.
+
+---
+
+## Deprecated Standard Objects and Features
+
+### Activities: Task and Event (Classic)
+
+Task and Event objects are not deprecated, but their classic user interface
+(Activity History related list in Classic UI) is. All activity management
+should use the Lightning Experience activity timeline.
+
+### Contracts (Status Field Values)
+
+The `Contract` object's `Status` field picklist values are not customizable
+in all editions. Review any automation that depends on hardcoded contract
+status values.
+
+### Documents Object
+
+The `Document` object (legacy file storage associated with folders) is
+functionally deprecated in favor of ContentDocument (Salesforce Files / CRM
+Content). New development should use ContentDocument, ContentVersion, and
+ContentDocumentLink.
+
+```sql
+-- Find code referencing Document object (legacy)
+-- Check Apex classes for 'FROM Document' queries
+SELECT Id, Name, ApiVersion
+FROM ApexClass
+WHERE Body LIKE '%FROM Document%'
+```
+
+### Chatter (Legacy Objects)
+
+Several legacy Chatter objects and APIs have been superseded by newer
+collaboration features. Review use of:
+- `FeedItem` (preferred over legacy `UserProfileFeed`).
+- Legacy `Chatter API` endpoints (superseded by Connect REST API).
+
+---
+
+## Salesforce Classic vs Lightning Experience
+
+Salesforce Classic is not officially deprecated for all orgs but:
+- New features are Lightning-only.
+- Lightning Experience is required for Salesforce mobile app.
+- Most ISV managed packages are Lightning-only.
+
+**Detection:**
+```sql
+SELECT Id, Name, UserPreferencesHideChatterOnboardingSplash, UserPreferencesLightningExperiencePreferred
+FROM User
+WHERE IsActive = true
+  AND UserPreferencesLightningExperiencePreferred = false
+  AND Profile.UserLicense.Name != 'Guest'
+LIMIT 200
+```
+
+Users still preferring Classic should be reviewed for migration readiness.
+
+---
+
+## Managed Package Lag
+
+Managed packages installed from AppExchange may not be updated to current
+Salesforce releases promptly. Outdated packages can:
+- Reference deprecated APIs.
+- Conflict with new Salesforce features.
+- Introduce security vulnerabilities.
+
+**Detection:**
+```sql
+SELECT SubscriberPackage.Name, SubscriberPackageVersion.MajorVersion,
+       SubscriberPackageVersion.MinorVersion,
+       SubscriberPackageVersion.BuildNumber,
+       SubscriberPackageVersion.ReleaseState
+FROM InstalledSubscriberPackage
+ORDER BY SubscriberPackage.Name
+```
+
+Check each installed package's AppExchange listing or vendor documentation
+for the current supported version.
+
+**Package lag risk:**
+- Package > 2 major versions behind: HIGH risk of deprecated API usage.
+- Package with no updates in 12 months: MEDIUM risk; verify vendor support status.
+
+---
+
+## Deprecated Metadata Review Checklist
+
+- [ ] Active Workflow Rules inventoried and migration plan documented.
+- [ ] Active Process Builder processes inventoried and migration plan documented.
+- [ ] No Apex code on API versions below the org's minimum supported version.
+- [ ] No Flows on API versions more than 5 versions old.
+- [ ] Document object usage reviewed — migrated to ContentDocument where possible.
+- [ ] Managed packages are within 1-2 major versions of current release.
+- [ ] Users still on Salesforce Classic identified and migration plan created.
+- [ ] SOAP API integrations checked for deprecated API version usage.

package/skills/salesforce/salesforce-metadata-review-skill/references/field-hygiene-rules.md

@@ -0,0 +1,182 @@
+# Field Hygiene Rules Reference
+
+Standards for naming, cleaning, and managing custom fields in Salesforce
+to prevent metadata bloat and maintain org health.
+
+---
+
+## Naming Conventions
+
+### Custom Field API Names
+
+| Object Type | Convention | Example |
+|-------------|-----------|---------|
+| Standard field extension | Descriptive suffix | `Account.PreferredChannel__c` |
+| Boolean field | `Is` prefix | `Contact.IsVerified__c` |
+| Date/DateTime fields | Verb + Date | `Opportunity.CloseRescheduledDate__c` |
+| Count fields | `Count` suffix | `Account.ActiveCasesCount__c` |
+| External ID | `ExtId` or system name | `Contact.SFMCContactId__c` |
+| Currency fields | No currency symbol in name | `Opportunity.EstimatedBudget__c` |
+| Formula fields | Indicate computed nature | `Opportunity.DaysOpenFormula__c` |
+
+### Label Naming
+
+- Labels are user-visible; API names are developer-visible. They may differ.
+- Labels should be human-readable and title-cased.
+- Avoid technical jargon in labels.
+- Avoid label changes after the field is in use — label changes affect reports,
+  list views, and page layouts.
+
+### Namespace Conventions (Managed Packages)
+
+All fields in managed packages include the namespace prefix:
+`namespace__FieldName__c`
+
+In unmanaged orgs, avoid creating field API names that conflict with common
+managed package namespaces.
+
+---
+
+## Custom Field Bloat Indicators
+
+Field bloat makes orgs harder to maintain, slows schema lookups, and confuses
+developers and admins.
+
+### Quantitative Thresholds
+
+| Object | Custom Field Count | Health Status |
+|--------|------------------|--------------|
+| Account | < 50 | Good |
+| Account | 50-100 | Review — identify unused |
+| Account | > 100 | Bloated — cleanup required |
+| Contact | < 40 | Good |
+| Opportunity | < 60 | Good |
+| Any custom object | > 100 | Bloated |
+
+These are guidelines, not hard rules. Objects with complex data models may
+legitimately exceed these counts.
+
+### Detecting Unused Fields
+
+```apex
+// Run this in anonymous Apex to get field counts per object
+Map<String, Integer> fieldCounts = new Map<String, Integer>;
+for (Schema.SObjectType objType : Schema.getGlobalDescribe.values) {
+    String objName = objType.getDescribe.getName;
+    Integer fieldCount = objType.getDescribe.fields.getMap.size;
+    if (fieldCount > 50 && objName.endsWith('__c')) {
+        System.debug(objName + ': ' + fieldCount + ' fields');
+    }
+}
+```
+
+### Using Field Usage Reports
+
+Salesforce Setup provides field usage reports:
+Path: Setup > Schema Builder > (select object) > Fields tab > Sort by "Last Used"
+
+Or use the Salesforce Optimizer:
+Path: Setup > Salesforce Optimizer > Run (generates field usage report)
+
+Fields with no usage in the last 90 days in production are candidates for review.
+
+### Before Deleting a Field
+
+1. Check all Apex code for references: `grep -rn "FieldName__c" force-app/`
+2. Check all Flows referencing the field via Metadata API.
+3. Check all Reports using the field.
+4. Check all List Views.
+5. Check all Page Layouts.
+6. Check all Validation Rules.
+7. Export field data for archival before deletion.
+8. Delete the field in a sandbox first and run all tests.
+
+---
+
+## Formula Field Complexity Limits
+
+Salesforce enforces formula size limits:
+
+| Limit | Value |
+|-------|-------|
+| Characters in formula (compiled size) | 5,000 characters |
+| Characters in formula (uncompiled source) | 3,900 characters |
+| Cross-object references per formula | 10 |
+| Date/time function calls per formula | 10 |
+
+### Formula Optimization Patterns
+
+**Anti-pattern: Deeply nested IIF/IF chains**
+```
+IF(Status__c = 'A', 'Alpha', IF(Status__c = 'B', 'Beta', IF(Status__c = 'C', 'Gamma', 'Other')))
+```
+
+For more than 3-4 branches, use a custom Apex trigger to compute the value
+and store it in a regular field. Formulas cannot be easily extended and hit
+complexity limits.
+
+**Pattern: Text-based CASE equivalent**
+```
+CASE(Status__c,
+  'A', 'Alpha',
+  'B', 'Beta',
+  'C', 'Gamma',
+  'Other'
+)
+```
+
+CASE formulas are more readable and compile smaller than nested IFs for
+picklist-matching logic.
+
+**Cross-object formula depth limit:**
+Formulas can reference fields up to 10 hops in a relationship chain.
+`Opportunity.Account.Owner.Profile.Name` is 4 hops — within limit.
+Deeply nested formulas referencing many cross-object fields increase query
+complexity when Salesforce resolves them.
+
+---
+
+## Field Types and Data Integrity
+
+| Field Type | When to Use | Common Misuse |
+|------------|-------------|--------------|
+| Text | Short free-form text | Using for structured data (dates, IDs, amounts) |
+| Text Area | Multi-line free text | Using for structured JSON (use LongTextArea or a related object) |
+| Long Text Area | Descriptions, notes | Storing binary-encoded data |
+| Rich Text | Formatted HTML content | Storing user-supplied HTML without sanitization |
+| Number | Integer or decimal amounts | Storing phone numbers (use Phone type) |
+| Currency | Monetary amounts | Multi-currency amounts need currency field type, not number |
+| Picklist | Fixed-value categorical data | Using free-text where picklist provides governance |
+| Multi-select Picklist | Multiple values from fixed set | Using for data that has many legitimate values (use related object) |
+| External ID | External system reference ID | Creating duplicate external IDs |
+| Formula | Computed read-only values | Attempting to store mutable state |
+
+### Multi-Select Picklist Cautions
+
+Multi-select picklist fields are stored as semicolon-delimited strings.
+They cannot be:
+- Used in SOQL with `=` operator (use `INCLUDES` or `LIKE` with `%value%`).
+- Reliably indexed.
+- Efficiently queried when values need to be joined.
+
+```sql
+-- Correct SOQL for multi-select picklist
+SELECT Id, Name, Tags__c
+FROM Account
+WHERE Tags__c INCLUDES ('Enterprise', 'Partner')
+```
+
+---
+
+## Field Hygiene Checklist
+
+- [ ] Custom field count per object is within healthy thresholds.
+- [ ] All custom fields have populated Description fields.
+- [ ] Fields not used in the last 6 months flagged for review.
+- [ ] Formula fields do not exceed 5,000 compiled characters.
+- [ ] Cross-object formula references are minimized (< 5 hops when possible).
+- [ ] Multi-select picklists used only where appropriate (not as a substitute for related objects).
+- [ ] External ID fields are indexed.
+- [ ] Boolean fields use the `Is` prefix naming convention.
+- [ ] No duplicate fields covering the same business concept.
+- [ ] Legacy integration fields from decommissioned systems are removed or documented.

package/skills/salesforce/salesforce-metadata-review-skill/references/object-design-patterns.md

@@ -0,0 +1,187 @@
+# Object Design Patterns Reference
+
+Reference for Salesforce custom object design including relationship types,
+junction objects, OWD considerations, and sharing model design.
+
+---
+
+## Relationship Type Selection
+
+### Master-Detail vs Lookup
+
+| Dimension | Master-Detail | Lookup |
+|-----------|--------------|--------|
+| Required on child | Yes (always) | Optional |
+| Cascade delete | Yes — child deleted when master deleted | No — lookup becomes null |
+| Roll-up summary fields | Available on master | Not available |
+| Sharing inherited | Child inherits master's sharing | Independent |
+| OWD override | Cannot have OWD on detail; uses master's | Own OWD |
+| Record ownership | Child has no owner; master's owner controls | Child has own owner |
+| Max per object | 2 master-detail | 40 lookups |
+
+### When to Use Master-Detail
+
+Use master-detail when:
+- The child record cannot exist independently of the parent.
+- Roll-up summaries (SUM, COUNT, MIN, MAX) on the parent are required.
+- Child records should be automatically deleted when parent is deleted.
+
+Examples:
+- `OrderLineItem` is master-detail to `Order`.
+- `OpportunityLineItem` is master-detail to `Opportunity`.
+- Custom `ProjectTask__c` is master-detail to `Project__c`.
+
+### When to Use Lookup
+
+Use lookup when:
+- The child may exist without a parent (nullable foreign key).
+- The child record has its own sharing model independent of the parent.
+- The relationship is many-to-many (junction object pattern).
+
+---
+
+## Junction Object Pattern
+
+A junction object implements a many-to-many relationship by having two
+master-detail relationships (or two lookups) pointing to the two related objects.
+
+### Design Example: Contact — Event (Many-to-Many)
+
+```
+Contact (1) <--- EventAttendee__c (junction) ---> (1) Event__c
+```
+
+```apex
+// EventAttendee__c fields:
+//   Contact__c   : Master-Detail to Contact
+//   Event__c     : Master-Detail to Event__c (second master-detail)
+//   Status__c    : Picklist (Registered, Attended, Cancelled)
+//   RegistrationDate__c : DateTime
+
+// Query all events a contact attended:
+List<EventAttendee__c> attended = [
+    SELECT Event__c, Event__r.Name, Event__r.StartDate__c, Status__c
+    FROM EventAttendee__c
+    WHERE Contact__c = :contactId
+      AND Status__c = 'Attended'
+    ORDER BY Event__r.StartDate__c DESC
+];
+```
+
+### Junction Object Sharing Considerations
+
+When both sides of a junction object are master-detail:
+- The junction object's sharing is controlled by the object that is most
+  restrictive (intersection of both masters' record access).
+- If Contact is Private OWD and Event is Public Read Only, the junction
+  record is accessible only to users who can access BOTH the Contact AND
+  the Event.
+
+When lookup relationships are used instead:
+- The junction object has its own OWD and sharing rules.
+- More flexible but requires explicit sharing configuration.
+
+---
+
+## Organization-Wide Defaults (OWD)
+
+OWD is the baseline access level for records when no sharing rule or explicit
+ownership grants access.
+
+### OWD Options by Object Type
+
+| OWD Setting | Meaning |
+|-------------|---------|
+| Private | Only record owner and users above in role hierarchy can access |
+| Public Read Only | All users can view; only owner and hierarchy can edit |
+| Public Read/Write | All users can view and edit |
+| Public Read/Write/Transfer | All users can view, edit, and transfer ownership |
+| Controlled by Parent | Detail object inherits access from master object |
+
+### OWD Recommendations by Data Sensitivity
+
+| Object | Recommended OWD |
+|--------|----------------|
+| Account (B2B) | Private (territory-based visibility) |
+| Account (B2C) | Private |
+| Contact | Controlled by Parent (if linked to Account) or Private |
+| Opportunity | Private |
+| Case | Private (customer service owns case visibility) |
+| Lead | Private |
+| Product (Pricebook2/Product2) | Public Read Only |
+| Campaign | Public Read/Write |
+| Custom operational object | Private (safest default; relax via sharing rules) |
+
+### Tightening OWD Without Breaking Functionality
+
+Moving from Public to Private OWD requires:
+1. Identify all users who currently have access and should retain it.
+2. Create Sharing Rules to restore needed access.
+3. Identify Apex code using `without sharing` — review whether it over-exposes.
+4. Test in a full sandbox with representative user profiles before production.
+
+---
+
+## Sharing Model Design
+
+Salesforce sharing works in layers. Access is granted by ANY of the following:
+
+```
+1. OWD (baseline)
+2. Role Hierarchy (managers see subordinates' records)
+3. Sharing Rules (criteria-based or ownership-based)
+4. Manual Sharing (user grants access to individual record)
+5. Apex Managed Sharing (programmatic, custom ShareObject records)
+6. Teams (Account Teams, Opportunity Teams)
+7. Territory Management (if enabled)
+```
+
+### Sharing Rule Types
+
+| Type | How It Works |
+|------|-------------|
+| Owner-based | Records owned by users in group A are shared with group B |
+| Criteria-based | Records matching field criteria are shared with a group |
+| Guest User sharing | Special rules for Experience Cloud guest users |
+
+```sql
+-- Query sharing rules (Metadata API recommended for full detail)
+-- List Group-Based Sharing rules via Tooling API
+SELECT DeveloperName, SharingGroupId, AccessLevel, UserOrGroupId
+FROM AccountShare
+WHERE RowCause = 'SharingCriteriaRule'
+LIMIT 200
+```
+
+### Apex Managed Sharing
+
+For complex sharing requirements that criteria-based rules cannot express:
+
+```apex
+// Share a custom object record with a specific user
+CustomObject__Share share = new CustomObject__Share;
+share.ParentId = recordId;
+share.UserOrGroupId = userId;
+share.AccessLevel = 'Read';
+share.RowCause = Schema.CustomObject__Share.rowCause.Manual;  // or a custom reason
+
+Database.SaveResult result = Database.insert(share, false);
+```
+
+Apex managed sharing persists across record changes but must be explicitly
+removed when access should be revoked.
+
+---
+
+## Custom Object Design Checklist
+
+- [ ] Relationship type (master-detail vs lookup) documented with rationale.
+- [ ] OWD for new object set to Private as a starting point.
+- [ ] Sharing rules defined for all required access scenarios.
+- [ ] Roll-up summaries identified and implemented where master-detail exists.
+- [ ] Custom object has a meaningful naming convention and namespace consideration.
+- [ ] Object description field populated (visible in Salesforce documentation).
+- [ ] Record types defined if multiple business processes share the object.
+- [ ] Junction objects used for genuine many-to-many relationships (not a lookup array).
+- [ ] External ID field defined if records will be upserted from external systems.
+- [ ] Audit fields (CreatedDate, LastModifiedDate) expected behavior documented.