Resco Field Sales+
Resco Field Sales+ provides offline mobility to your sales solutions built on top of Microsoft Dynamics 365 Sales or Salesforce Sales Cloud. It allows your salespersons to connect with your customers in remote landscapes or locations with high security where the internet connection is limited. Field Sales+ includes lead management, activity management, email integration, dashboard, calendar, maps, account and contact management, and more.
Resco sales solution helps to:
- increase external sales productivity with AI image recognition, digital signatures, GPS, location tracking, or integrated inspections functionality.
- manage leads and deal statuses, opportunities and tasks while are your sales reps or field agents on the move.
- customize the app to increase user adoption and eliminate unnecessary clicks
Components
The Resco mobile sales solution is based on the versatile Mobile App Development Toolkit with the following main components:
- Resco Mobile CRM – A mobile app that grants you access to your sales data and processes right on your mobile device, even offline
- Custom app project – a pre-configured version of the app
- Woodford – configuration tool for modifying the app projects to match the needs of your organization better
Basic sales entities
This section describes the main entities of mobile sales projects on the Resco Cloud backend. However, much of the information also applies to sales processes in general.
The Account entity represents your business partner or your customer. It holds basic information about the account, like contact information and address. If you open the Account form in your app, you can also see a list of associated (related) Contacts and Opportunities.
Resco models the sales process in the following way:
The entity Lead represents an individual or company with an interest in buying your product (e.g., responded to your advertising, liked your post on social media, spoke to you at a conference). Leads have ratings - hot, warm, cold. Leads are considered temporary and companies usually have a qualification process set to determine whether the lead is a viable customer. This usually involves some communication between the salesperson and the lead.
If the salespersons decide a lead is qualified, they select this option in the app. The state of lead changes, a new opportunity is created, and, if the lead is a new customer, a new account and contact, too. The Opportunity represents a potential sales transaction - it usually contains more information than a lead (e.g., estimated revenue).
After creating the opportunity, the sales team determines what products and/or services are of interest to the customer. Once all the products/services are selected, a Quote can be generated from the opportunity. This quote is sent as a proposal to the customer for acceptance.
An accepted quote can generate an Order, and the associated opportunity is closed as won. Once the order is fulfilled, an Invoice is generated to bill the customer.
Another interesting entity is Product. It represents either a physical inventory item (such as lumber or a nail) or service (such as a haircut or tree pruning) that a company sells. Products from the product catalog can be used to build quotes and orders and can be associated with opportunities or service cases.
To count a product price, use the entities Price List and Price List Item. A price list defines pricing levels. A price list item informs how to price a product in the specified pricing level, including pricing method, rounding option, and discount type. Pricing is done based on a specified product unit (box, package, kilogram...) stored in an entity Unit.
Products and price list items
When adding Products to Sales Order, a new record of Order Product entity is created in the runtime of the mobile client. Use Price Lists, Units, and Price List Items properties of these added products. A similar principle applies to all sales entities (Quotes, Opportunities, Invoices).
To run all the background price calculations correctly, there are some prerequisites that must be met.
- The Order must have Price List and Currency lookup fields defined.
- Per each Product you’d like to work with, there must exist at least one Price List Item record.
- These are the required fields for Price List Items:
- Currency
- Price List
- Product
- Unit
- Quantity Selling Option
- Pricing method
- Amount (when Pricing Method is Currency Amount)
- Percentage (when Pricing Method is other than Currency Amount)
In the Product List selection in the mobile app, you see only those Products whose Currency and Price List lookup fields are in compliance with Sales Order field selection. The pricing information and prices calculations are based on the same logic as in the default Dynamics Sales scenario, see Microsoft documentation for more information.
Write-in products
Not all products must be included in the product catalog. You can use write-in products to add an ad hoc product to your opportunity.
To enable write-in products, enable the fields Write-In Product (productdescription) and Select Product (isproductoverridden) for the "Opportunity Line" entity in Woodford. If you disable the fields, the button for adding write-in products is no longer available.
A similar function is also available for orders and quotes. Enable or disable the fields on the entities "Order Line" and "Quote Line".
Rounding policy on price list items
Consider the following third-party blogs if you need to understand the various rounding policies on price list items. This behavior applies to Dynamics and Resco Cloud organizations. Blog
Special behavior of child lists
Resco Mobile CRM supports special handling for child lists, which are available for sales child entities.
A child list is an associated list on the form that targets the child entity of the form entity, e.g., Opportunity Product list on Opportunity form. The complete list of child entities follows:
| Dynamics | Salesforce | |
|---|---|---|
Sales
|
Field Service
|
|
The specialties of child lists are:
- Changes to the child list using the UI are not saved directly to the database but stay in memory until the parent form is saved.
- For sales entities (but not field service), a multi-lookup form (sometimes called "shopping basket") is used to manage items in the list. In this form, products are on the left and line items on the right. This behavior is hardcoded and cannot be enabled for other entities.
- Such lists can be configured using Woodford.
- For line items, define an associated view (right side).
- For products, define a lookup view (left side).
Changes in release 17.2
- Refresh on changes outside the parent form
- Since release 17.2, records in child lists are automatically refreshed when the same records are changed outside of form, e.g., via custom JavaScript, via rules that load and save records, or on another open form. This behavior is consistent with regular associated lists. Prior to version 17.2, changes made outside child list and detail form were ignored. Note that in case of list records being modified, the external change will discard any un-saved changes.
- Support for bulk update
- You can use bulk update on the child entity list on the parent form. Changes are performed in memory, and the child list is automatically refreshed.
- Child lists work correctly when more than one child entity is defined.
- While it is possible to have a custom entity with a lookup to the same parent as a child entity to be marked as Parent Pointer, prior to version 17.2, this also caused the child entity list on the parent form to become a regular associated list. This setup led to inconsistent behavior and multiple problems, such as changes not done in memory, child forms becoming read-only, and other semi-random validation issues. Since 17.2, the behavior has been fixed, so the child lists are always initialized as expected.