Design layer

Salesforce integration with Django web portal

Salesforce integration with Django web portal

Our company has experience in developing and supporting the portal (custom website) that is integrated with Salesforce and has different levels of access for different groups of stakeholders. We’ve synchronized all the data (accounts and their statuses, opportunities, service prices, metadata, etc.) between our portal and Salesforce. So the data is constantly transferred between Salesforce and our portal back and forth via Celery and Redis. For this, we’re using the latest version of Salesforce API.

Developing a complex integrated system gives us lots of challenging business problems to solve. Here we are going to describe some of the cases, that we had while developing an NDA project.

Terms and definitions for better understanding

Salesforce — one of the most popular CRMs.

Web portal — client's custom website, developed on Python, Django. Our client sells and provides services to their customers via this portal (SaaS model).

Operationists have access to Salesforce: they manage income, spending, and prices. Also, they see the performance of the Sales Team.

The Sales Team has access to Salesforce CRM: they manage accounts in their different statuses (prospect, cold, hot) and close the deals.

Support Team – have NO access to Salesforce, only to the portal, where they see the info about clients, but not prices and their spending.


Case 1

The Support Team is getting an inquiry from a customer about the service they need to acquire on our portal.

How it was back then:

  • The support manager has no access to Salesforce, so when they get an inquiry they transfer it to the Sales team.
  • The sales manager makes requested changes in Salesforce and sends this info back to the support manager.
  • The support manager then needs to contact the system administrator to make the actual changes on the server.
  • The support manager gets the info, that the required task is done and goes back to the client to inform them, that everything's ready.

As you can see, this process has too many steps and people involved. It spends lots of time and creates situations, where this complex system will eventually fail and result in a bad experience for clients. Because the more steps and people in the process the more mistakes might occur.

How it is now:

  • The support manager gets an inquiry from the client, enters the client's account at our portal, and makes changes.
  • Changed settings in a portal automatically transfer to Salesforce, apply the changes on the back-end, and configures the server in a new requested way.
  • The client gets an automated notification of his now available new service.

This automated process resulted in a much faster performance with fewer people involved and without back-tracking.


Case 2

To explain this case we need to introduce one more group of users – Tenants.

Tenants are also the customers of the portal, but they have their customers. They can add their accounts, service prices and manage all of them in one place on our portal. They have no access to Salesforce and cannot see the activities of other tenants. Sales managers at the same time can track the activity of all tenants, their opportunities, contacts, prices, etc.

Our role in the creation of this system was to synchronize all the data between the portal and Salesforce. For instance, when a tenant has one of his opportunities closed won – this info is automatically launched to the Data Center and the service is provided to the final client without directly involving the Sales Team.

line

Get our specialist's advice

Name*

Email*

What’s your estimated budget for this project?*

Describe you project

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

line
design

Looking for an enthusiastic team?