Just Keep Dreamin'

Author: Dhruv

  • Simplify user management via User Access Policies

    Does complex security and sharing requirements at your organization complicate user provisioning? Does making sure that each user is set up with the correct permission sets, added to the right public groups and granted necessary package licenses require a 20 page reference document?

    Generally available as of Summer ’24, User Access Policies dramatically simplify user provisioning and make sure that no steps fall through the cracks. Join us as we explore UAP and different paradigms for supercharging user provisioning and management.

  • How Data Cloud came to be, and why it may (not) matter for your small/mid-sized organization

    It is NOT a Database.
    It is NOT a Data Lake.
    It is NOT a Data Warehouse.
    It is NOT Master Data Management (whatever that is)

    So what IS Data Cloud? Why did it come to be?

    Does it really take a whole new team/skillset to implement?
    Why do I hear it the same breath as Marketing Cloud and AgentForce?

    Does my small/mid-sized enterprise/school/nonprofit need to care about Data Cloud when I only have one Sales Cloud instance?

    Join us as we break down Data Cloud, analyze where it fits in the technological landscape and determine if/when your organization should care.

  • Marketing Cloud (Growth/Account) Engagement

    Join us as we compare the capabilities of the various Salesforce marketing automation offerings, share the skills required (functional and technical) to support either of those products, and help you ident

  • Flow architecture paradigms: Finding that sweet spot between one-per-object and one-per-requirement

    First there were workflow rules, where each rule accomplished exactly one goal.

    Then there were process builders, wherein each Process aimed to create a complete picture of everything happening to that object. (“Where best possible, of course”).

    Then came Flows, and soon exited (pushed out?) WF Rules and Process Builder, and the SF Admin world was both wonderful and chaotic ever after.

    First came official guidance to create one flow per object, then one type of flow per object. Then came Flow Trigger Explorer, so actually, one per object wasn’t so necessary anymore.

    What about performance?

    How do we manage technical debt?

    (How) should we distribute logic between record-triggered flows or invocable sub-flows or platform event flows?

    I know I should do “what’s right for my organization”, but what is right for my organization which, by the way, is a [10,000 user MNC]/[mid-sized enterprise, whatever that means]/[5-person nonprofit with a solo admin].

    Join this session as we explore different paradigms for architecting your flows, share best practices for different use cases, and discuss tools & strategies for managing change while lowering technical debt.