My sales data

Description

++Scenarios++

First of all, the user can log in using their data from Salesforce completely safely using the modern OAuth 2.0 connection protocol. Thus, our application does not know any information about the user, but only gets the opportunity to perform a list of some actions on his behalf.

You can enter already in the Production database, or use a test version of the database, the so-called Sandbox. In the near future, we will erase the boundary between these databases, and the user will be able to easily send information from production to the sandbox and in the other direction.

Basically all the work is done using the REST service. But this API is not available for users who have Professional edition. In this case, we offer the opportunity to use the SOAP protocol.

Each user can upload a report to his page in a spreadsheet or information in the object. The information received from the report is only locally changeable, all changes on the page will not affect the information in the salesforce system in any way.

In addition, the user can download any information from the object using the generated SOQL query. To optimize work, you can save queries to templates, and the next time you call them. Queries from such templates can be easily changed before uploading the information.

For the convenience of work, you can get information on the attributes of each field tied to the active page of the object.

The refresh command will update all information on the page using the query. For example, the user uploaded 6 records (1..6). Then he decided that he would not work with records 3 and 4, and then removed them from the page (not from salesforce!). Then the user remembered that he needed these 2 records. The refresh command will unload all entries that match this query and highlight conflicts.

The user can choose whether to update the information for only one page or for several.

Using the merge command, the user will get the current information only for those records that are currently on the page. As in the case of refresh, conflicts will be highlighted.

The user can send the information he changed to the server using the Force Push command. In this case, all the information on the page will be unloaded and the changes will change what will be on the server. For example, John and Jack unloaded a contact with id = 1. John changed his name from the contact with Fred to Ivan, and sent them to the server. Thus, Jack is not aware of the fact that the changes already applied have sent their changes. As a result, Jack could not even find out that he ruined someone's work. But this method is very relevant, if one person always works with the data.

The push command will first check whether there have been any changes to the data, whether there will be conflicts, and ask the user to solve the conflicts at the beginning.

The removal is implemented in two variations: automatic mode (it also applies when sending data to the server) and in manual mode. Automatic mode assumes that the user has changed the color of the cell that stores the id from black to red. Such Id will be deleted. In the manual mode, the user must select in real time which id he wants to delete.

Also the addon supports several languages. The database of languages ​​can easily be supplemented by the request of the buyer.




++Description++

In the development of this addon, we were inspired by the simplicity of working with version control systems, which themselves determine all the changes and send them to the server.

We offer several editions of our application, so each user can find what he needs exactly and do not pay too much.

Login under your account in the salesforce system on production or sandbox

Use different APIs (REST)

Use different APIs (SOAP)

Get data on existing reports

Get data from the salesforce system using SQOL and a handy SOQL query generator

Using templates that store SOQL

Get information about the fields of the object that is currently working

Update information on request for one page

Update information for multiple page requests

Merge local changes with information that is now stored on the server, get information about existing conflicts (the operation affects only local data)

Force push. Send your changes to the server, copying the changes that were made by someone before

Push. Send your changes to the server, before it will merge. This will make it convenient for several users to work at once.

Uninstall in automatic mode, using the backlight for cells that stores the id

Manual deletion: a sidebar is opened, the user selects the id that he wants to delete, and then he presses the delete button. Id for one transaction should stand side by side.

Multilingualism.

Support by email for the duration of the subscription.

Set the timer on the page for automatic force push and receive a report on the changes by email. (in developing)

Setting the timer on the page for automatic push and getting a report about the changes by email. The user can choose in advance where the difference is considered correct. (in developing)

All the same as in the previous paragraph, only the user can specify a rule not only for the entire page, but for each individual cell. Also adds the ability in case of conflict to transfer all the information as a backup to another page, which will no longer be associated with salesforce, but will be marked as a backup, and there will be an opportunity to merge this page with the one that was the original fork. (in developing)

The ability to easily translate information from the production database into the sandbox, and vice versa. (in developing)