Gautam Kumar

Business Problem

Teams were manually creating and organizing Google Drive folders for every Account, Lead, and Contact — slow, inconsistent, and easy to get wrong at volume.

Requirements

Automatic folder creation on record creation, structured hierarchy matching Salesforce's object relationships, and a way for users to reach synced files without leaving Salesforce.

Architecture Overview

Trigger-driven Apex on record creation calls a service class, which makes an authenticated callout to the Google Drive API. Returned folder IDs are written back to custom fields, and a Queueable job handles retries on transient callout failures without blocking the user transaction.

Data Model

Custom fields on Account/Lead/Contact store the Drive folder ID and sync status; a Custom Metadata Type holds environment-specific API configuration so the integration can move between sandboxes without code changes.

Security Considerations

OAuth 2.0 with a dedicated connected app scoped to Drive access only; named credentials keep tokens out of code; field-level security restricts who can view sync status fields.

Technical Components

• Apex Classes: DriveSyncService, DriveCalloutQueueable, DriveSyncTriggerHandler
• LWC: driveFileViewer, syncStatusBadge
• Flows: record-triggered flow for manual re-sync
• Integration: Google Drive REST API via OAuth 2.0

Challenges & Solution

Google API rate limits meant bulk record creation could throw callout errors mid-transaction. Solved by moving the callout to an asynchronous Queueable with exponential backoff, decoupling the sync from the user's save action.

Results & Lessons Learned

Eliminated a manual folder-organization step from the team's workflow. Biggest lesson: design for API failure from day one — the retry logic mattered more than the happy path.

Future Enhancements

Batch reconciliation job to catch and repair any records where sync silently failed; audit log of all sync events for troubleshooting.

Business Problem

Users had to manually browse structured library records to find relevant books and resources — slow, and unhelpful for anyone unsure exactly what to search for.

Requirements

A conversational interface that could recommend books, search library data in natural language, and surface learning resources without needing report-building skills.

Architecture Overview

Built on the Agentforce Agent Library, with the agent grounded against structured library object data and configured actions for search and recommendation intents, so responses stay tied to real records rather than generic AI output.

Data Model

Existing library custom objects (books, categories, availability) exposed to the agent through defined actions rather than duplicated into a separate data store.

Security Considerations

Agent actions respect the running user's existing object and field-level permissions — no elevated access granted purely for the AI layer.

Technical Components

• Platform: Agentforce Agent Library
• Actions: book search, recommendation, resource lookup
• Data: structured library objects + multimedia resource links

Challenges & Solution

Early responses were too generic when library data was sparse for a given category. Solved by tightening the grounding actions so the agent explicitly says when it's short on matching records instead of guessing.

Results & Lessons Learned

Gave non-technical users a much faster path to relevant resources. Key lesson: a narrow, well-grounded agent beats a broad, loosely-configured one.

Future Enhancements

Usage analytics on which queries the agent can't answer well, to guide what data gets added next.

Business Problem

Object customization, workflows, and reporting for customer feedback tracking were handled piecemeal, creating manual reporting overhead and inconsistent data entry.

Requirements

End-to-end automation covering feedback capture, routing, and reporting, without adding steps to the user's existing process.

Architecture Overview

Record-triggered Flows handle routing and validation at the point of entry; declarative automation was preferred over Apex wherever governor limits and complexity allowed, keeping the solution maintainable by admins after handoff.

Data Model

Custom feedback object related to Accounts and Cases, with validation rules enforcing required context before a feedback record can be routed.

Security Considerations

Sharing rules scoped so feedback is visible to the owning team and management roles only, not org-wide by default.

Technical Components

• Flows: feedback intake, routing, escalation
• Validation Rules: required-field and data-quality checks
• Reports/Dashboards: feedback trend and resolution tracking

Challenges & Solution

Balancing "keep it declarative" against a few edge cases that needed more control than Flow offered cleanly — resolved with small, targeted invocable Apex actions called from Flow rather than full custom logic.

Results & Lessons Learned

Reduced manual effort in feedback handling and gave the team visibility they didn't have before. Lesson: declarative-first isn't a purity rule — it's a maintainability trade-off, and it's fine to drop into Apex for the 10% that needs it.

Future Enhancements

Feed feedback trends into the Agentforce library assistant so common issues surface proactively.