#Be A Builder – Data Model

 

  1. Project
    1. Purpose
      1. Primary object for the app
    2. Key Data
      1. Account (Lookup to Account)
      2. Project Owner (Lookup to User)
      3. Description of project
      4. Timeline Information
        1. Project start date
        2. Project end date
      5. Project status
      6. Status Update (Most recent status update)
  2. Project Team Members (Identify Key Stakeholders)
    1.  Purpose
      1. Tracks users (project stakeholders) involved in the project
    2. Members
      1. Sales reps
      2. Astro designers
      3. Project Managers
    3. Key Data
      1. Name (Lookup to Users)
      2. Email (Formula)
      3. Phone (Formula)
      4. Role (Global Picklist)
        1. Sales Representative
        2. Project Manager
        3. Designer
  3. Project Updates
    1. Purpose
      1. Used to provide status updates on the project.
    2. Key Data
      1. Status Update
      2. Created by User
      3. Created by Date
      4. Status
    3. Automation
      1. Added to the project
        1. Status Update
        2. Project Status
  4. Tasks
    1. Purpose
      1. Milestones and Todos related to the project
    2. Existing Object
    3. Relationship
      1. Each project can have multiple tasks
  5. Events
    1. Purpose
      1. Meeting related to the project
    2. Existing Object
    3. Relationship
      1. Each project can have multiple events
  6. Notes
    1. Purpose
      1. Notes captured during the life of the project
    2. Existing Object
    3. Relationship
      1. Each project can have multiple notes
  7. Files
    1. Purpose
      1. Pictures and files provided by the client or designs teams
    2. Existing Object
    3. Relationship
      1. Each project can have multiple files
  8. Account
    1. Purpose
      1. Business accounts we do with business with
    2. Existing object
    3. Relationship
      1. Each account can have multiple projects
  9. Contact
    1. Purpose
      1. Contact at business
    2. Existing object
    3. Relationship
      1. Each account can have multiple contacts

Day3

#Be A Builder – Gather Requirements

Gathering Requirements

  1. Identify Key Stakeholders
    1. Sales reps
    2. Astro designers
    3. Project Managers
  2. Ask Key Questions:
    1. What are your pain points?
      1. Spreadsheet information gets lost in email
      2. Don’t know who updates what
      3. Unclear what the timelines are
    2. What is the current process?
      1. Sales Rep
        1. Make Sale
        2. Fills out spreadsheet
        3. Send completed spreadsheet to project manager
      2. Project Manager
        1. Assigns a designer
        2. Assigns a production team
        3. Schedules meeting with team
        4. Meets with Team
          1. Outcome – Timeline Defined
        5. Email sales rep Timeline
      3. Sales Rep
        1. Emails/Phones customer with updates
      4. Project Team begins work
    3. Who is involved? Who is affected?
      1. Sales rep,
      2. Designer,
      3. Production team,
      4. Project manager
    4. How is the spreadsheet being used?
      1. To collect and share vital information
    5. What does the future look like? How can you plan ahead?
      1. We may start making cloudys and codeys (they have a different production process)
  3. Determine data that needs to be collected
    1. Leadership wants to know:
      1. how long projects take,
      2. how many projects we complete in a quarter,
      3. success rate,
      4. trends in Astro plushy orders.
    2. Data helps the business see understand:
      1. Project capacity,
      2. Employee performance,
      3. The popularity of plushy orders.
    3. Possible data to track:
      1. Project start date
      2. Project end date
      3. Team Roles
      4. Description of project
      5. Pictures or mockups of Astro designs
      6. Project status

 

#Be A Builder – Identify the Problem

“The first step of the app building journey is to identify the problem.”

USE CASE: Astro Nomica – A custom plushy astro manufacture, uses Salesforce for their sales team. Unfortunately, once the sale is completed they rely on Email and Spreadsheets to share information. Project Manager then send the data to the development team

  • Sample Spreadsheet Data
    • How many units
    • Size
    • Design
    • Customer
    • Status Updates

Lets build an app to replace the manual process of emailing the spreadsheets to the team

  • What is in Salesforce
    • Step 1 – Talk to your Sales team to see how they are using Salesforce.
    • Step 2 – What are the processes they are tracking in Salesforce.
  • What is not in Salesforce – The Messy Part
    • Emails and spreadsheets
      • What processes are tracked
      • What is the data
      • Who is the audience

ASTRO NOMICAL need our help!

#Be A Builder – Awesome Admin Sweepstakes

If you are involved in the Salesforce community, you are aware that Salesforce promotes lifelong learning of its platform as services. The new #BE A BUILDER sweepstakes is another example of their dedication to get the community involved and learning.

BeABuilder – A 10-day learning adventure where admins  build a business app from start to finish.

Salesforce has broken down the app building process into 10 steps. Each day a new step will be revealed .

Day Name Key Features Resources
1
Identify the Problem
  1. Understand how users use Salesforce
  2. Know your business inside and out
  3. Identify manual processes
2
Gather Requirements
  1. Identify Stakeholders
  2. Real Requirements (Ask WHY)
    1. Pain Points
    2. Current Process
    3. Future Process
  3. Understand Data Requirements
    1. How is the data going to be used
3
Build a Data Model
  1. Write down data to capture and report on
  2. Consider existing objects
  3. Define how object relate
4
Design awesome UX
  1. Think about feature
  2. Make it Intuitive
  3. Incorporate Best Practices
  4. Leverage Lightning App Builder
5
Ensure Great Data
  • App is only as good as its data
  • Prevent user errors by
  • reduce manual input
  • Incorporate validation rules
  • Enforce data process
Link to video
6
Define Permissions
  • Grant users access to new custom app
  • Define app access for project app with custom profile
  • Add access to other types of users using permission set
Link to Video
7
Automation
  • Use automation to reduce manual data entry, create reminders and save time
  • Consider the automation funnel when choosing the right automation tool
  • Process builder is always first consideration
Link to Video
Leverage AppExchange & Components
  • First Customize with standard components
  • Explore and Install AppExchange components
  • Build Custom lightning Components to address your customization needs
Link to Video
9
Create reports & dashboards
  • Build reusable custom report to feed all your dashboard components #OneReportToRuleEmAll
  • Enable Dashboard feed for collaboration and optimization
  • View and refine important data with filters
Link to Video
10
Make It Mobile
  • Your data model, user experience, and reporting is available on mobile
  • Enhance the mobile experience with actions
  • Customize the mobile experience with branding
Link to Video

Visual Flow – Cross Object Formulas

 

Salesforce Notes:

Tips for Cross-Object Field References in Flows

Cross-object field values are valid wherever you can reference a flow resource or manually enter a value. Keep these implementation tips in mind when you use a cross-object field reference.
Available in: both Salesforce Classic and Lightning Experience
Available in: EnterprisePerformanceUnlimited, and Developer Editions
When you create an sObject variable to reference fields on related records from, store the ID for the first related record in the variable. For example, to reference an opportunity’s contract, store ContractId in the sObject variable or add a value for ContractId by using an Assignment element.

Unsupported Relationships

The following relationships aren’t supported in cross-object field references.

  • Lead.ConvertedAccount
  • Lead.ConvertedContact
  • Lead.ConvertedOpportunity

Avoiding Null Values

If a flow interview encounters a null value at any point in the cross-object expression, the element containing the reference fails. The reference runs successfully if the last field value in the expression is null. For example, store a contact in {!sObjContact} and try to reference {!sObjContact}.Account.Name. The flow fails if AccountId on the stored contact is null (because there isn’t an account to look at), but it succeeds if Name on the related account is null.

If an element contains a cross-object reference that fails and the element doesn’t have a fault path defined, the entire interview fails. To avoid this situation, you can:

  • Make the fields that you want to reference in the expression required in Salesforce. For example, for the expression {!sObjContact}.Account.Name, you could require AccountId on contact page layouts. Then, using another flow, find any records with null values for that field and update them.
  • Determine whether each field that’s referenced in the expression has a value by using the wasSet operator in a Decision element.

Cross-Object Field References and Org Limits

Cross-object field references in flows don’t count against your org’s limits for:

  • Cross-object relationships per object
  • DML operations per transaction

Cross-Object Field References in Flows: Simple Relationships

Most relationships are straightforward. For example, Case.AccountId links directly to the case’s parent account. If you know that a field relationship ties your object to exactly one other object, use this syntax.
Available in: both Salesforce Classic and Lightning Experience
Available in: EnterprisePerformanceUnlimited, and Developer Editions

To reference a field on a related record, use this syntax.

1 {!sObjectVariable.objectName1.objectName2.fieldName}
where:

  • sObjectVariable is the unique name for the sObject variable that you want to start from.
  • objectName1 is the API name for an object that’s related to sObjectVariable’s object type. The API names for all custom objects end in __r.
  • (Optional) objectName2 is the API name for an object that’s related to objectName1.

    Your expression must include at least one object name, but you can add more objects as needed.

  • fieldName is the name for the field that you want to reference on the last object in the expression. The API names for all custom fields end in __c.

For example, {!sOv_Contact.Account.Id} references Id of the account that’s related to the contact record represented by an sObject variable in the flow.

 

Cross-Object Field References in Flows: Polymorphic Relationships

Some fields have relationships to more than one object. We call these relationships polymorphic. For example, if you have queues enabled for cases, a case owner can be either a user or queue. If you’re traversing from a case to its owner ID, add special syntax to identify which object you mean when you say “Owner”.
Available in: both Salesforce Classic and Lightning Experience
Available in: EnterprisePerformanceUnlimited, and Developer Editions
To reference a field on a related record, use this syntax.

1 {!sObjectVariable.polymorphicObjectName1:specificObjectName2.fieldName}
where:

  • sObjectVariable is the unique name for the sObject variable that you want to start from.
  • polymorphicObject is the API name for a polymorphic relationship for sObjectVariable‘s object type.
  • specificObjectName is the API name for the object that you want to select from the polymorphic relationship.
  • fieldName is the name for the field that you want to reference on the last object in the expression. All custom field API names end in __c.

For example: {!sObj_Case.Owner:User.Id} references the ID of the user who owns the case, while {!sObj_Case.Owner:Queue.Id} references the ID of the queue who owns the case. You can always add the polymorphic reference after several traversals ({!sObj_Case.Account.Owner:User.Id}) or in the middle of a reference ({!sObj_Case.Owner:User.Manager.Id}).

Supported Polymorphic Relationships

Not every relationship is polymorphic, so we recommend using the polymorphic syntax only when you know that the field can link to multiple objects. The following relationships are supported.

  • Case.Source
  • FeedItem.CreatedBy
  • Object.Owner

    Where Object lets you set Owner to either a user or a queue. Group.Owner and Queue.Owner aren’t supported.

When you create an sObject variable to reference fields on related records from, store the ID for the first related record in the variable. For example, to reference an opportunity’s contract, store ContractId in the sObject variable or add a value for ContractId by using an Assignment element.

 

Example Cross-Object Field References in Flows

This example demonstrates how to update a contract’s owner to be the contract’s account’s owner.
Available in: both Salesforce Classic and Lightning Experience
Available in: EnterprisePerformanceUnlimited, and Developer Editions

Example

Example of a flow that references cross-object fields

  1. Use a Fast Lookup element to store the contract’s fields, including AccountId, in an sObject variable called varContract.
  2. Use a Decision element to verify that the value of AccountId was set in varContract.
  3. Use a Fast Lookup to store the fields for the contract’s account, including OwnerId, in another sObject variable called varAccount.
  4. Use a Decision element to confirm that the value of OwnerId was set in varAccount.
  5. Use an Assignment element to specify {!varContract.Account.OwnerId} as the value for {!varContract.OwnerId}.
  6. Use a Fast Update element to write the values in varContract, including the updated OwnerId value, to the contract in Salesforce.

Examples:

Opportunity Owner Name

Formula: {!sobjOppty.Owner.FirstName} & " " & {!sobjOppty.Owner.LastName}

 

Reassigning Email to Case to User who Forwarded Case to Salesforce

Business Use Case

Bobby DoRight is working as a System administrator at Skeletonforce.  He receives a request to have Cases created using from emails automatically assigned to the user who forwarded the email from outlook.At Skeletonforce, end users receives support emails directly from their clients in Outlook.

If Bob was follow the instructions in “Set Up Create Case for Salesforce for Outlook Users”, Bob would need to create individual Email to Case routing addresses for each user. He would then group 10 Email-to-Case destinations into functional group and assign them through Outlook Configurations. Users then select their name from the CREATE CASE button in outlook. This is confusing for the end user and a maintenance nightmare for Bob to keep track of. … there has to be an easier way.

Solution

Luckily for Bob, Salesforce stores the From Address for all Cases created from email. This stored information along with PROCESS BUILDERS and FLOWS will allow Bob to automatically reassign cases based matching the from email address with a user’s email address.

Objects & Fields Used

Object Fields
Users Id
Users Email
Case Id
Case OwnerId
Email FromAddress
Email ParentId

Process Builder

Settings Reference Image
Object Case (Create and Edit)
Criteria Specify Specific Recordtype and or Queue ownership

IsNew()

PB011718_001

PB011718_005

Scheduled Actions

0 hours after last modified date

Trigger Flow

– Pass Case.Id to varCaseId

PB011718_003

PB011718_002

PB011718_004

Flow

FL011718_001

Settings  Object  Criteria Reference Image
Fast Lookup Email Emails with Case Id

FL011718_005

Decision HasEmail sobjEmail is not null

FL011718_011

FL011718_006

Fast Lookup User User with matching email

** Not really needed

FL011718_009

Assignment Case case.ownerid equals user.id

FL011718_004

Fast Update Case

FL011718_012

## Testing

Test in a sandbox, not in Production.

Continue reading “Reassigning Email to Case to User who Forwarded Case to Salesforce”

Action Plans …. Reinvented Using Flows

INTRODUCTION:

If you have been using Salesforce for awhile, you may installed and used Action Plans by Salesforce Labs to automate standardized/repetitive processes. This appexchange app was and still is a very useful addon for any Salesforce instance. Customizing Action Plans to meet specific project needs while still keeping it’s simple universal appeal can be problematic. Especially if you are not comfortable with making changes to multiple APEX modules and VISUALFORCE pages.

Process Builders and Visual Flows to the rescue:

One of the best gifts Salesforce ever provided Administrators are Process Builders and Visual Flows. These two autmation tools allow users to automate Salesforce instances without needing a Salesforce Developers.

Business Need: Skeleton Bob has been asked to create a process that will allow product specific onboarding/change procedures. These procedures will consist of specific task to be completed by both non-Salesforce users and Non-Salesforce users.

After working with the line of business, Bob defined the resuable task templates, assigned user and/or teams for each product. He tried to use Action Plans, but the business line needed to many changes specific to them that would have changed Action Plans users in other line of businesses. Bob instead mimics Action Plan’s design using new objects and extends functionality with visual flows.

Design Components:

 

Design Components:

Note: A new blog post will be used for each component’s details

  • Objects:
    • Action Plan Flow Templates
      • Action Plan Flow Template Tasks
      • Action Plan Flows
        • Action Plan Flow Tasks
        • Links Parent Accounts
  • Custom Settings:
    • Action Plans Settings
      • Chatter Brag
      • Unassigned Tasks Defaults to Record Owner
  • Process Builders:
    • Action Plan Flow Template Task – PB
    • Action Plan Flow – PB
    • Action Plan Flow Task – PB
    • Task – PB
    • PARENT ACCOUNT
  • Visual Flows:
    • Action Plan Flow Template – Autolaunched Flow
    • Action Plan Flow Template Add Edit – Screen Flow
    • Action Plan Flow Template Task – Autolaunched Flow
    • Action Plan Flow Template Task Add Edit – Screen Flow
    • Action Plan Flow – Autolaunched Flow
    • Action Plan Flow Add Edit – Screen Flow
    • Action Plan Flow Task – Autolaunched Flow
    • Action Plan Flow Task Add Edit – Screen Flow
    • APFT Task Dependencies – Autolaunched Flow
    • APF Task Dependencies – Autolaunched Flow
    • APF Add Case Teams – Autolaunched Flow
    • APF HTML Emails – Autolaunched Flow