Nerd @ Work

When Salesforce is life!

[ORGanizer Sponsorship Program] Merlin Guides joins our trailblazing sponsors

 

Today for the next month Merlin Guides joins ORGanizer’s trailblazing sponsors!

Merlin Guides stops your team from making mistakes in Salesforce. By guiding your team, step by step, inside of Salesforce with your interactive guides, your team will know your exact process and exactly the information they need to fill out. Every guide is created in minutes (by just doing the process once yourself) and they are completely custom to your team – your process available whenever the team needs it.

We’re the only solution available in the AppExchange that supports guides that work inside and outside (Bazaar Voice, Asana, Jira…etc) of Salesforce, so we’re great for the complex processes your customer support & sales teams have to go through.

Merlin decreases mistakes, increases adoption and improves your data – by scaling the best training in your company in the best possible way.

Find out more!

Merlin Guides will keep company to you in the coming month on the ORGanizer popup page…and hopefully more than this!

Click the link and find out their incredible service!


If you are interested in joining the program, leave a message on the ORGanizer Sponsorship Program form.

May the Force.com be with you all!

[Salesforce / IoT] Let’s play the game with Salesforce IoT (part 3): Heroku IoT platform

 

In the previous post we have setup everything needed on the Salesforce side to configure the IoT Explorer.

Before jumping on the Arduino Nutellator 3000 project, we have to create a proxy that will transform data received from the devices in order to push them to our beloved CRM.

For those, like me, who are the typical TL;DR developers, head over the GitHub repository and have a look at this simple NodeJS project.

What do we need?

  • A Salesforce Connected App
  • An Heroku dyno to host the proxy (our own IoT Platform)
  • An Heroku Postgres Database (free tire) to handle basic authentication

What will this app do?

The main job of this app is to create Platform Events filled with the data that comes from the Nutellators and send this events to the IoT Explorer to finally trigger the orchestrations.

N.B. If the last sentence is totally obscure to you, please go back to the first post of this series to learn more about Platform Events and how they are related to Salesforce IoT.

Configure a connected app on the CRM

To send a Platform Event using the REST APIs, you’ll need a Connected App.

To create a new one go to Setup > Apps > Connected Apps and create a new app:

We won’t be needing the callback URL since (so put a protocol://fake formatted url) we’ll be using Username-Password OAuth Flow (more details here).

From this app you need the following info to properly configure the Heroku app:

Next thing you need your user’s username/password/token to complete the Oauth process.

Setup Heroku

Create a new Heroku app (let’s say iot-nutellator.herokuapp.com).
Fork the salesforce-iot-nutellator-proxy repository on GitHub.

Click on the Deploy tab and link the forked Github repository:

Do not deploy the code right now.

Add the Heroku Postgres add-on and set everything up

Jump to the Resources tab and look for Heroku Postgres addon (choose the free tier):

Let’s put some settings

Before deploying the code from GitHub we have to setup few settings on the Settings tab:

You should have seen the DATABASE_URL already there: this is the url to access the Postgres database.

Deploy

Go back to the Deploy page and hit the Deploy branch button:

Last action to make is executing the DB initialization code that creates a iot_user table with a single user called “user” with password” pass: this user (and any other you decide to add) will be used to authorize every request from the device using basic authentication.

To execute the script simply use the Heroku console:

Test it out!

Open the app on your browser using https://your-app-name.herokuapp.com.
If everything is ok you should see this message:

Salesforce IoT Proxy 
© Enrico Murru - blog.enree.co 2018

Anatomy of the proxy

The Express JS server exposes 2 different routes:

  • GET /: doesn’t actually do anything
  • POST /api/level: this is the route used by the devices to send their data

A typical call would be so formatted:

POST /api/level

Headers
Authorization: BASIC BASE64(user:pass)
Content-Type: application/json

Body
{
    "level": 30,
    "device_id": "T1-C0DE-IRI"
}

Where device_id is the Devide Id that we’ve seen in the Nutellator Salesforce object and level is the nutell-level of the device in %.

The result of such a call is an update triggered by the orchestration on the targeted device:

In the next and last post we’ll be closing the post series by having fun with Arduino and a Nutellator 3000 project.

[ORGanizer Sponsorship Program] The Welkin Suite in the heart of ORGanizer

 

Standing ovation for The Welkin Suite, new ORGanizer sponsor for the next month!

We are proud to say that we are the only one-stop tool for Salesforce that effectively removes the pain and greatly speeds up work for Configuration, Administration, and Development.
Our informative design and Intuitive usage allows easy access to sObjects, Field usage reports, FLS editing, inspectors for Fields and layouts, abilities to clone Fields, easy deployments and Org comparison, SOQl, and more. Plus code development for Apex, Lightning, Visualforce, and tools for managing Debugging, Governor Limits, Code Coverage, test running and the list goes on.

The only powerful tool for both Salesforce development and administration– with tools for Apex/Lightning/Visualforce/Declarative Development, and for managing Debugging, SOQL Queries, FLS, sObjects, Governor Limits, Code Coverage and much more with its 100+ features

The Welkin Suite will keep company to you in the coming month on the ORGanizer menu button…and hopefully more than this!

Click the link and install their amazing IDE!


If you are interested in joining the program, leave a message on the ORGanizer Sponsorship Program form.

May the Force.com be with you all!

[ORGanizer Sponsorship Program] sfApex is our newest sponsor!

 

Just 2 days before the first ORGanizer Sponsorship Program announcement, we are here to give a warm hug to sfApex into our Ohana!

sfApex is a leader in Salesforce data copy.
Quickly and easily populate your sandboxes with data for better testing and faster development.
Their customers experience a 50-70% reduction in time spent populating sandboxes.
You can copy all your data or select specific records to meet your testing criteria.
Eliminate the pain of writing scripts or trying to match thousands of record IDs in Excel.
Spend more time coding and less time creating test data.

sfApex will keep company to you in the coming month on the upper side of the main ORGanizer page…and hopefully more than this!

Click the link and install their astounding sandbox populating app (and ofcourse leave your 5 star review)!


If you are interested in joining the program, leave a message on the ORGanizer Sponsorship Program form.

May the Force.com be with you all!

[Salesforce / VCS] Develop VS Deliver Features in Salesforce

A devs life could be so easy…

Developing a feature in Salesforce is easy, right?

  • Log into your org
  • Use (mostly) some point &bmp; click methods to enhance logic, user interface or the data model
  • Done

Sounds like it is developed.

But it is not delivered.

Although the feature is technically done, it is not available for end users in the production environment. Also, nobody tested if it fits the business requirements or if it breaks existing functionality.
In addition, maybe someone should take a look at your feature, if it is aligned with the overall solution design.
Oh, and in order to minimize business impact, deployments to production may be restricted to specific time windows per week.

Sounds like we as a team should follow a process to release features in a controlled way.

This is how we roll

There are a variety of processes for release management out there as each team is individual, but usually they structure a series of quality gates in a flow.
Taking the example from above, the high-level process would probably look like this:

So far so good, but now we have a challenge.

Production deployments can only be done at certain moments so what happens, if one feature is tested and ready to go and another one is still being reworked, and both share components such as an Account Layout?
Oh, and we want to have a backup of our metadata (not only classes) to be able to roll back, in case we have an issue after deployment?

It would be great, if we could work in a way that tracks changes over time and allows to release specific versions of our metadata.

Git for the save.

As described above, developing on the Force.com platform can be very straight forward. But apart from Flows and Process Builder, old versions are lost, once you save your changes, e.g. Classes, Formulas, Validation Rules or Layouts.
To avoid that, you can store local copies of your metadata by retrieving it (e.g. through Workbench or ANT Migration Tool). You can also deploy the retrieved items. So we could use that to account for our prod deployment, but that sounds like a lot of effort to manage those local files and versions.

Here is where a Version Control Solution (VCS) comes in handy. And by the frequency VCS is being mentioned, it has become an important pillar for working with Salesforce. There are several solutions out there (SVN, Mercurial), but as of now Git can be considered industry standard.

So instead of storing retrieved items on our hard drive using different names and folders for tracking versions, we can simply store them in our Git repository, which will track changes. This will allow us to go back to an earlier moment for rolling back changes or deploy a specific version from the past.

That escalated quickly. Can it be easy again?

Let’s take a step back.

What started out as an easy way to build valuable business features, suddenly sounds somewhat complex. Being able to roll back, having quality gates in place, all those are valid points, but now as a developer apart from creating functionality and work peer and QA feedback, you also need to do something with ANT or Workbench then storing it in Git and then deploy it?
Is there an easy way to do this?

Yes, Copado.

To get started, you need to download it from the AppExchange or the Copa.do website. Also, as the goal is to work with version control, get a free Git repo from GitHub or Atlassian/Bitbucket.
Next you need to connect Copado to your Salesforce environments (Dev, QA and Prod in this case) and set it up with the Git repository. There is a quick-start guide you can follow with links to additional documentation. While you set up Copado, you notice that it is natively build on the force.com platform. So your knowledge about Salesforce is all you need to modify it (This will be important later, so keep it in mind).

Once the setup is done, the process described out above using Git version control as source of truth would be the following with Copado:

Define feature in Copado

Assuming most Salesforce implementations are done in some form of Agile, it can be done in Copado directly, including all required information, such as Sprints, Epics, Acceptance Criteria or Story Points (click here for more details).

Scrum Masters and Analysts can use the Work Manager and Kanban Board to manage stories, roadmaps and sprints.

Develop feature in your environment

Let’s get to the part we like: get creative on how to solve the business issue in Salesforce. This one is easy indeed.

Perform a peer review in your environment

This is done between developers, however, we would like to document the results with a flag to mark the story as “Review Passed”.

Here is when the catchphrase “native force.com” turns into a benefit.
Just create a Checkbox on the Copado User Story object called “Peer Review Passed”, make it available for the required User Profiles and put it on the User story layout. Done*.

*: Wait, you work in Production directly? You can use Copado to deploy this modification.

Deploy to QA

So far so good, let’s go ahead and deploy. Scared?

Just click on “Commit Changes” on the Copado User Story, select your items (use column search and sorting to make your life easy), provide a message and finish your commit.

Back on the User Story page, check “Promote & Deploy”* and the following will be done by Copado**:

  • Create a feature branch
  • Retrieve the items you selected
  • Commit the items you selected on the feature branch
  • Create an intermediate Promotion Branch merge your feature branch on it (more info on the branching strategy can be found here)
  • Perform the deployment using Git as source
  • You can review your selections on the story, and click on the “View in Git” links to quickly navigate to your repository.

    ** bonus points if you click on “Validate” to make sure you can deploy

    Test user story

    Once the story is deployed to the next environment, it will be visible on the User Story page and we can change the status to “Ready for testing” and notify the Test Team through chatter.

    If you are thinking “Wait, this just a record update in Salesforce and it could be automated easily”, you are completely right! Wait for the upcoming blog posts.

    As soon as the test team approves the story, they can set the status to “Complete”.

    Deploy to Production

    Testing is done, and we can move to Prod. But wasn’t there something about other stories modifying the same component and them not being ready?
    Well, this is the beauty of version control. Copado will pick the feature branch contents for deployment and those did not change. Your story is independent and you can work in a true Agile way.

    Check “Promote & Deploy” again.

    Done.

    That’s it. That’s all?

    Well, not exactly. The tool offers tons of functionality which can make your life easy, such as the way profiles are trimmed and deployed with Git, an engine to remove (or replace) unwanted tags from xml files, modules for recording and automating testing, and the easiest way to handle Salesforce DX you have ever seen. You can even launch internal Copado logic through Process Builder!

    Check out on their demos or browse a little the documentation to get an overview of what is possible.

    We, however, will leave technical feature descriptions aside and focus at improving our process, as there are elements which will need to be tackled to get your team closer to smooth releases.

    • You’ll never work alone, so how to improve releases by working as a team?
    • Deploying with a simple click is maybe too easy. Can we implement quality gates?
    • Those are too many clicks. Can we automate this?

    Look out for the next post, where we will take a closer look at the involved team members and how Business Analysts can play a key role reducing the time required to release a feature.

[ORGanizer Sponsorship Program] Welcome to LuminosityCRM, our first sponsor!

 

After 2 years and a half of free time programming the #BestSalesforceExtensionEver, I’m rolling out the ORGanizer Sponsorship Program.

You should already have seen new banners on the ORGanizer main extension’s page or the info links on the ORGanizer button or Quick Console: they’ll be soon replaced by awesome companies and trailblazers who want to support the ORGanizer to keep it free for all!

Give your warmest welcome to LuminosityCRM, our first sponsor!

LuminosityCRM is a Salesforce appExchange partner.

They develop top-rated apps that simplify cloning and editing hierarchies of records for companies of all sizes around the world. Their apps, Super Clone and Super Clone Pro allow Salesforce administrators to implement a cloning process in minutes.

LuminosityCRM will keep company to you in the coming year on the bottom side of the main ORGanizer page!

Click the link and try their amazing cloning app (and leave your 5 star review)!


If you are interested in joining the program, leave a message on the ORGanizer Sponsorship Program form.

May the Force.com be with you all!

[Salesforce / IoT] Let’s play the game with Salesforce IoT (part 2): Setup an Orchestration

Here we go with the second part of the Salesforce IoT playground post.

Read the part 1 post before going on to get the whole context.

Let’s start playing with the Salesforce IoT Explorer Edition by enabling it on the Setup:

The Salesforce IoT platform gives you the means to build business processes with point-and-click: you are still able to create triggers and complex logics, but now you have a simple tool that can be used to orchestrate your IoT information flow (aka Nutellator refills).

As you can see from the image above, new setup items apper:

  • Contexts: the configuration that matches platform events (Nutelleven__e) to Salesforce objects (Nutellator__c)
  • Orchestrations: this is the logic you build up to create powerful state machines that represent your Nutellators’ live state
  • Usage Data: lists all the orchestrations running on your Org

Let’s put all together

The Salesforce IoT Explorer flow is quite simple and works this way:

  1. IoT data comes from outside in form a HTTP post requests using REST APIs and Platform Events: data can be transformed and modified using Apex Triggers
  2. Each event is then coupled with actual Saleforce Sobject, the contetual data
  3. The context is then processed with Orchestrations which define state machines and translates state changes into business actions
  4. We have now Salesforce actions that can do whatever effect you want (external integrations, Sales / Service actions, …)

The Context

We have already defined the Nutellevent__e platform event and the corresponding Nutellator__c Sobject.

To couple them we should create a new IoT Context from Setup > Salesforce IoT > Contexts > New Context:

After the Context is created, let’s configure what’s inside. Click on Edit > Add Event data:

Select the main event and then the reference device ID that will be source to identify the context objects:

Now click on Add Reference data to complete the configuration:

Select the Nutellator Sobject and the unique field that represents the device:

Complete by hitting Save and then Done.

We are now able to link IoT data to Salesforce objects, such as knowing which device is sending data and which customer (Account) it belongs so.

Our first orchestration

It’s time to add logic to our IoT data to support our refill service.

Click on Setup > Salesforce IoT > Orchestrations > New Orchestration:

Our orchestration is meant to monitor the Nutella levels on the devices, so we are expected to have 3 different states:

  • Normal level: level is way above the minimum nutel-level, nothing to do here!
  • Warning level: we have reached a warning level, we have enough Nutella but it’s about to drop under the danger threadshold. This state is particularly important if we have different Nutellator for a given customer, and the support technicians could pro-actively refill more than one device when only one is under the danger level
  • Empty level: this is the danger level. From now on the Nutellator could finish soon its delicious sauce: it’s time to act not to let the customer without happiness.

To create a new state simply click the + Add State button (don’t worry if your colors differs from the following picture, I had to create and delete more states to match the idea behind the warning and danger ideas):

Switch to the Variables tab and let’s create the warning and empy threadsholds:

These variables should be used to evaluate the level received in the IoT data and to make the proper state transition. Let’s go back to the Rules tab and create a new rule for each state:

From NormalWarning when the level drops under the warning level, from Warning jump to Empty when the level drops under the empty level and finally when in Empty if the level rises up we’ll have a state transition to Warning (which can finally go to Normal.
We are using the Warning level as a “proxy” state of transition between the normal and danger states.

Click on the States tab to have a look at the state machine:

Let’s add some more actions.
When a new event comes, we want to keep track of the level on the Nutellator__c object as you can recall from the Nutellator tab on our Nuterllator 3000 app:

We can add a new action of each state that simply updates for any given incoming Nutellevel__e platform event the corresponding Nutellator__c object:

Click on the Add rule of the rule’s context menù (the three dots on the right side of the rule’s title), select Nutellevent__e on the when column, leave condition blank and set Salesforce record on the action column:

Select the Nutellator__c object and click Edit and select the following configuration:

Replicate this action on the other rules: you cannot use the Global Rules, because this kind of rules can only be used to reset context variables (such as counters, i.e. you could decide to activate the support process only if the state machine remains in the empty state for a certain amount of events received and not immediately).

Finally we need to start our support process if the level drops under the empty level.

Before adding this action, create a Nutellator__c lookip field on Nutellator__c object on the CaseEmpty Nutel-level state, stating that a new Case record should be used when state is entered (when column compiled with the State entered and a Salesforce record action):

This is the detail of the so configured Empty level:

Finally activate the Orchestration using the Activate button:

Let’s play the game!

Everything have to start with a platform event, which can be created via:

  • Apex code
  • HTTP post request

For the purpose of this post, we’ll go with the first method, and here is the execute code (made with the Execute Anonymous plugin of the ORGanizer for Salesforce Chrome & Firefox extension):

Nutellevent__e event1 = new Nutellevent__e(Nutellator_ID__c = 'TI-C04-41R1', Nutellevel__c = 99);
Nutellevent__e event2 = new Nutellevent__e(Nutellator_ID__c = 'T1-C0DE-IRI', Nutellevel__c = 99);
List<Database.SaveResult> results = EventBus.publish(new List<Nutellevent__e>{event1, event2});

We expect 2 different things:

  • Level and date/time of event are written on the Nutellator__c objects
  • The Orchestration’s state machine should have 2 devices on the Normal state (Orchestration’s Traffic tab)

Now let’s take one of the two devices and make its level drop under 30%:

Nutellevent__e event1 = new Nutellevent__e(Nutellator_ID__c = 'T1-C0DE-IRI', Nutellevel__c = 25);
List<Database.SaveResult> results = EventBus.publish(new List<Nutellevent__e>{event1});

Finally let’s drop under the 10% level and a new Case is expected to be automatically created:

Nutellevent__e event1 = new Nutellevent__e(Nutellator_ID__c = 'T1-C0DE-IRI', Nutellevel__c = 9);
List<Database.SaveResult> results = EventBus.publish(new List<Nutellevent__e>{event1});

And here is the Case related to the device:

With the given configuration you may have experienced a strange behavior: when changing state, the level on the Nutellator__c object is not updated.

This is caused by the order of the rules, that should be evaluated in the correct order: if rule makes a state transition before updatin the record, the record is simply not updated. The solution is to move the update rules before the state transitions:

What’s next

Now that we have all setup on the Salesforce platform, we can setup the real IoT platform (using Heroku?) that will send Salesforce the IoT data (transforming raw data into Platform Events) and I’ll show you how to build an Arduino powered device that will simulate the Nutellator 3000.

See you in the next post!

[Salesforce / IoT] Let’s play the game with Salesforce IoT (part 1): let’s get started

 
Have you ever heard of IoT before? I strongly believe so, it is one of the most trending topics everywhere.

It’s all about things (i.e. devices) that are connected through the Internet and can become smart by sharing their data.

Devices are only the first part of the IoT world: we cannot think of IoT without the “T” of things and we cannot think of IoT without the “I” of internet.

That said, the involved actors behind the “I” of Internet are not sentient machines that are ready to use devices data to rule humans (actually not yet) but actually platforms that can collect, elaborate and route this tiny pieces of data to make the devices actually smart!

What I want to say is that your toothbrush is not smart until you connect it on the Internet and make it talk with the “Toothbrush Factory Inc.” platform, which will hestimate your toothbrush consumption and alert you on your smartwatch or make an automatic order to Amazon.com, so you’ll receive the day after your new toothbrush head without even knowing you needed a new one!

What about Salesforce?

Salesforce is your toothbursh factory platform for Sales!

I guess the guys at Salesforce won’t like so much this similitude, and they may be right, because there is an actual distinction: Salesforce IoT is not an IoT framework that talks with the devices directly, but it is an application that works on the data produced by those devices, whose bits of data is transformed by proper IoT platforms (Google, Amazon, Microsoft, …) and consumed by Salesforce (who correlate that info with actual Salesforce objects).

This picture sums up the concept:

The Salesforce IoT product is meant to enhance your business by:

  • Combining devices data with Salesforce data to better understand devices usage
  • Orchestrating with code-less tools your business process around IoT data (you can still use “low level” Apex code to increase the complexity and customization level of your Org)
  • Increasing user engagement and customer perception (the customer knows he needs something only when the company tells him)

An example? Have a read at the dedicated Trailhead modules to better understand this concept.

An example please!

You own a company that provides rechargable Nutella stands: they are much like a coffee machine, the only difference is that the machine drops Nutella instead of coffee.

Author’s note: this is something that doesn’t exist, and it makes me really sad 🙁

You sell tens of machines all over you country and provide the “recharge” service as well, for an additional price.

Every Nutella device, which is connected via WiFi to the Internet, sends a data packet to your Google Cloud IoT instance telling the device ID and the amount of Nutella level (from now on called Nutel-level).

The platform takes those inputs and format them correctly so that Salesforce IoT platform can “eat” them (packaging them inside the so called Platform Events).

Whenever the nutel-level drops under a certain level, Salesforce IoT automatically activates its business process logic magic and a new Case is automatically opened and sent to the technicians along with a Work Order to start a field service operation.

Ready, get set, go!

Before activating the Salesforce IoT Explorer Edition let’s create the necessary metadata on our DE Org.

First we create a Nutellator__c custom object that represents the Nutella device with the following fields:

  • Device_ID__c: Text(255), unique, required, identifies a specific device by its unique id
  • Nut_level__c: Percent(3,2), % level of Nutella on the device (last measure)
  • Last_Measure_Date__c: Date/Time, date of last measure
  • Account__c: Lookup(Account), your customer
  • Location__c: Text(255), where the device is located

We could have used the standard Asset object, but I loved the idea of creating an object called Nutellator.

Second task is to create a Platform Event called Nutellevent__e: if you don’t know what a platform event is click here to learn more, but you can think of it as an ephemeral object that is not stored on the database but that can be used to trigger business logic.
The Nutellevent__e platform event is used to start the IoT flow on Salesforce: this object conveys the id of the device and the nutellevel percentage.

All is set up to start playing with Salesforce IoT Explorer Edition…but we’ll see it in the next post!

[Salesforce / AppExchange Series] Meet Accessnow, Salesforce Emergency and Privileged Access Management made easy!

This week’s guest post for the AppExchange Series has been written by Francesco Quinterno, founder of accessnow which built a Salesforce app to help emergency management…for more details jump down to this great post!

accessnow was founded by Atlanta based Francesco Quinterno and Lesley Morgan.
They’ve leveraged their experience while working for The Coca-Cola Company, Colgate-Palmolive, Warner Brothers, IBM and Coca-Cola Enterprises to build an application that enables Governance, Risk Management and Compliance on the Salesforce platform.
They can be reached at [email protected].


Our purpose as Developers, Admins, Architects is to deliver applications that improve the lives of our customers. When things go smoothly the user community is appreciative and fills us with praise. However, when things go wrong, it can be a lonely place with no praise. A place where everyone’s focus shifts to asking who and how the issue was caused. In these heated moments, it takes cool heads and swift actions to get the business “back into business.”

One of the critical tasks during an emergency is getting the right experts the right access as quickly as possible. It is not uncommon during these high pressure situations to neglect security and governance protocols and act in a non-compliant way. Sys Admins can provide super user access without any reference to an incident number or change request which is then further exacerbated when and if the access is not taken away. All the above are the ingredients for a failed audit in the months to come.

With accessnow, the premier Salesforce Emergency and Privileged Access Management application, you don’t have to compromise speed for compliance.

How?

Meet Maggie Greene, the IT Support User: when an emergency arises, Maggie creates an accessnow request.

She inserts:

  • a reference number (which can be an incident number or change request number from the Case, Servicenow, Remedy or any ticketing system)
  • the reason for needing the elevated access
  • duration of the request
  • start time (immediately or scheduled in the future)

She selects:

  • the profile and/or role
  • or permissions
  • or permissions and role
  • or a single role

Available roles/profiles/permissions are defined based on Maggie’s skillset and job function.
Once she’s selected everything, she saves and submits for approval.

At this point, the request is either automatically or manually approved based on configuration of who the requester is and what is being requested.

Notifications can be configured for all these stages. Requester can be notified of his request creation and approval. Approver can be notified there is a request pending approval.

On approval of the accessnow request, Maggie automatically receives elevated access to begin the troubleshooting process.

While troubleshooting, all changes to data, configuration changes and data views are captured in audit logs that are native to Salesforce.

accessnow also captures logs when users with an accessnow request use the Log In As function. Anyone viewing the audit logs will clearly see the changes to data or configuration were carried out by a person who was logged in as someone else.

In screenshot below Maggie Greene created request and used the Log in As function to log in as Darryl Dixon. While Maggie was logged in as Darryl she changed data on a case. She then logged out as Darryl and changed Data as herself.

Call Center Resource Management Use Case

During heavy call volumes you need help from other resources to answer the phones. Sys Admins shouldn’t be spending their valuable time changing profiles, permission sets, and roles for multiple people.

Call center supervisors create slots of time where help is required. Internal employees claim these slots and for every approved time slot, an accessnow request is generated and approved.
Once the request is approved the internal employee is assigned a Call Center profile for the time defined in the slot.

While working with the new profile, all activities are logged. Once the time elapses the internal employee’s Call Center profile is revoked and their original profiles are reinstated.

Reports

Dashboard showing the top users, request by status and the permission requested.

Value

The application’s value is that it eliminates the dependency on Sys Admins for granting and revoking temporary Privileged Access. It allows users to urgently gain temporary access on-demand and automates the approval of the request and revoking of the privileged access. It allows auditors to access logs of activities performed while users had privileged access without having to interrogate Sys Admins. The logging is vital for SOX Internal Access Controls. accessnow allows Architects and Sys Admins to implement the Least Privilege Security Model by reducing the number of permanent Administrators required in the system. It allows organizations to close the gap on GDPR articles 17, 19, 23 and 32.

Contact us at [email protected] for more information.

[Salesforce / Mobile] How to go mobile with Salesforce – Part 2

 
The second part of the guest post about Salesforce mobile adoption by our friend Barbora at Resco.net, who will analyze the issues to avoid when planning Salesforce mobile.

Barbora Piatrova (marketing specialist at Resco) takes her passion for digital marketing & Mobile CRM everywhere she goes. Currently, she’s involved in creating & mastering content strategy at resco.net – one of the leading companies in the world for Mobile CRM. She is now actively also discovering and participating in new thriving communities for Salesforce enthusiasts.


Issues to avoid when mobilizing your Salesforce data

Are you on edge when it comes to mobilizing Salesforce data to your users? Going mobile was never as easy as it is today. But is it secure and safe?

Well, it can be. If you choose the best possible scenario & set the right strategy. The goal is to get your sleek & robust Salesforce organization into phone and tablet – without losing the tools you know and prefer. And at the same time – gaining the productivity perks of native mobility as an extra.

Do you want to get your field reps prepped for a full-fledged mobile experience? Then be aware of the following issues. They cannot occur in your new application for Salesforce.

Integration & supported licenses

ISSUE: The app does not tie neatly into your Salesforce ecosystem and/or does not work with all the Salesforce licenses starting from the most basic one (Salesforce Essentials).

Platform availability

ISSUE: The app is not available on all major operating systems, for example it works only on iOS, Android, excluding Windows.

Security

ISSUE: Mobile data storage is protected, but only by user’s PIN. This means that if the user session (automatic logout after a few minutes) and app protection APIs are missing, the application and hence user data are not truly protected. All of this must be developed from the ground up. This requires complex engineering with a high risk attached to even a smallest oversight.

Offline syncing

ISSUE: The user is not able to determine what functions and formulas will operate when the app is being used offline.

ISSUE: The admin cannot regulate when and what is available for users to sync (manual & background sync, delayed publishes of Salesforce schema changes, etc.).

ISSUE: The app doesn’t allow sync of data when online for later offline backup or it syncs very slow in general.

Offline experience

ISSUE: The app is not reliable in offline mode, runs slowly and does not allow users to go offline for days without losing any of the previous work and data.

ISSUE: Admins and users can’t directly see how is the business logic mapped to the app execution.

ISSUE: When multiple users aren’t able to access, edit or change the same data offline.

ISSUE: Users are not able to configure offline datasets within the app or affiliated configuration tool.

Look ‘n feel to an end user

ISSUE: UI is not advanced and is out-of-date – the app lacks slick animations, static forms, sliding menus, interactive videos, scrolling text, interactive charts, tables, reports, and more.

Reputation & brand recognition

ISSUE: The app does not seem trustworthy, tested and proven. It doesn’t have the best reputation, bad ratings and reviews, customers that have bad experiences and do not recommend it.

Enterprise readiness

ISSUE: Your company purchases a mobile solution for Salesforce, but still doesn’t achieve the anticipated ROI. One of the reasons? It was simply not prepared for a change. Either you did not choose an app suitable for your business conditions or you did not set the right strategy, did not integrate it with your existing tools properly or did not involve your employees enough.

User adoption

ISSUE: The company does not involve users in any decision making processes, provide sufficient training, the app that doesn’t make their job any easier, because it is not easy to use, interactive and user friendly.

User tracking, audit and analytics

ISSUE: Admins are not able to track sales guys routes and locations during deployment to check compliance-GPS requirement. There is no on-site reporting or offline reports and alike features included in the app.

Flexibility in customizations & branding

ISSUE: It requires coding skills and it is not easy for a regular user to create custom objects, set rules and the functionality of objects. There are limited options to design the app for a company or even customer branding, limited object management for sales reps, and more.

Multimedia capturing

ISSUE: When all the data (photos, multimedia, geo-location services) are not captured locally. Data should be relevant to the app that is integrated with your device. It should not only enable you to capture, but to work with them – especially allow for real-time picture editing during visits and make it visible on the customer visit report.

Productivity

ISSUE: The productivity features have limitations or aren’t a part of the solution at all. Hence, the app doesn’t stress the functionalities to simplify the job of the remote workers. For example, users cannot update information on the go, and the mobile interface is not a simple action-based function, there is no easy access to notes or contact information. What else shouldn’t be missing? Contact import, calls, maps, email, push notifications, reminders, and similar.

Coverage

ISSUE: Losing connection with our product catalogue in the middle of a visit can be catastrophic and may even affect the relationship you have built with your customer. Therefore, you should be ready to always have the information available without depending on the cellular or internet connection.

Integrations

ISSUE: The more 3rd party tools and service integrations – the better. Companies increasingly demand more specific solutions to run their businesses smoother, easier and faster. If the app works as a single unit that does not efficiently communicate with external tools, it is not a suitable enterprise solution.

Language

ISSUE: Users do not have the opportunity to choose the app’s language according to the region/location, business unit or user role.

Price vs. App functionality

ISSUE: The app comes with one or more of the above-mentioned issues, and on top of that, it’s pricey? Then it may not be worth your time, money, and frustration.
If you want to mobilize Salesforce without having to run to any of such issues, here is a place to start: www.resco.net/salesforce.

Page 1 of 15

Powered by WordPress & Theme by Anders Norén