BrokerForce Replication and Synchronization Primer

BrokerForce™ Replication & Synchronization Primer

BrokerForce™ is a customer relationship and order management application designed for manufacturers' reps. It is used to manage contacts, customers, vendors (manufacturers or principals), accept and relay orders, and to track commissions. Your rep group (agency) has chosen to use the Enterprise version of BrokerForce™ so that you can work independently using a licensed copy of BrokerForce™ and a replica of their data.

A replica is something like a copy of your agency's data with some additional information added that is used to manage the integration of changes that you make with those made by your agency. These changes are integrated when your data set is synchronized with your agency's data. Since the added information keeps track of who changed what and when they changed it, do not make backup copies of your replica because it will damage this information and can make the entire replica set unusable. When you synchronize, you have an off-premises backup, the safest form of backup.

For the most part, synchronizing your changes to the agency's requires little or no intervention on your part. However, there are a few dos and don'ts that will simplify your use of the application and the synchronization process.

Synchronizing do's and don'ts

Understanding a bit about replication and synchronization can help make this process really work well for you. Replication is the process of creating multiple sets of related data, replicas, of a primary data set to be used at multiple locations that are not always connected to each other through a network. Collectively, the data sets are called a replica set. Your replica empowers you to make changes to the agency's database independently while you are not connected to the agency's network. When you synchronize, changes you have made are passed to the agency while changes they made are returned to your replica.
: Replication works very well for adding new records such as an order or a new account and potential problems can easily be avoided with a few simple guidelines. Replication does not work as well when multiple users are changing or adding the same records.; When a problem occurs that is related to the entry or changing of data by one or more users, it is referred to as a conflict. The most common type of conflict occurs when two or more users change the same record between synchronizations. A typical example would be if you changed a customer's information such as the phone number or address, someone in the office also changed the same customer's information, and then you synchronized. If this happens, you will be prompted just after synchronizing that "Data conflicts were encountered..." and will be offered the option to resolve these differences using the conflict resolution wizard.; The conflict wizard will show you what tables were involved, the record involved, and then display the two copies of the changed record in a side-by-side comparison. You should edit one of the two records to incorporate both changes and then click the <Resolve> button to reconcile your changes. After your resolve any conflicts, synchronize again to pass these changes to your agency. The agency must establish a policy for record changes that will reduce conflict possibilities. A policy that only the office should add new customers can eliminate duplicated customer records.
: Another type of conflict occurs if a validation rule is violated. Validation rules are used to enforce the integrity of the database. This type of conflict typically occurs under two types of circumstances: a duplicated value that should not have been duplicated is entered; or violations occur when a record is added that doesn't have a required relationship to another record such as an order being deleted by the office while the rep continues to add line item details to it before the deletion has been synchronized.; In the first case, a duplicate value that should be unique is entered: two users enter a new record for the same person or company between synchronizing. BrokerForce™ will not accept a duplicated vendor, customer, or contact record. Vendors' customer numbers and products must also be unique. Duplicates occur more often when you add a new record and don't synchronize for an extended period of time. Synchronizing frequently is the easiest way to avoid conflicts.

Avoiding duplicates examples

1) If you have a partial replica (only customers that you are assigned to) and add what you think is a new customer record when that customer is already in the agency's database, a duplicate violation occurs. Confirm that any customer is new to the agency before adding a new customer record. If the customer is not new, have the agency change the rep assignment and synchronized to pickup this change. If you must add a customer on-the-fly, add the city to the end of the name to help assure that it is unique e.g. "Acme Pleasantville"

2) Situation: You add a new customer, don't synchronize for a while, and the agency adds the same customer when the first invoices arrive before you synchronize causing a violation. Prevention: Synchronize as soon as you can after adding a customer.

3) A duplicate value violation occurs when you and the agency office person both enter an order or invoice for a customer and add a new vendor customer number when you are prompted that there isn't one. Communicate additions and synchronize shortly thereafter.

4) Another type of validation conflict can occur if one user deletes a record and another continues to add related records that depend on the former record. An example of this occurrence appears when one user deletes a customer record and another user continues to add orders for that customer before synchronizing. When the two data sets are synchronized, the orders added do not have a related customer record that they can be associated with. A similar problem will occur if an order is deleted and another user continues to add line item details, or a payment is posted to the deleted order. Communication and established company policy is the best way to avoid this potential issue.

Oops, I accidentally deleted something!

Don't synchronize!! Deletions always win in synchronization. If you accidentally delete something important, that deletion may cause a cascade deletion. For example, the deletion of an order will cascade the deletion to all of the order's line item details. You can restore that information by creating a replacement replica from another replica that hasn't been synchronized since the deletion was made. The new replica should have a different name. Although you will lose and may have to re-enter any data since the last time you synchronized, you can recover from this type of error.

How to Synchronize

To close BrokerForce™, click <, <Exit>. Pending that your data is a member of a replica set, this will bring up the synchronization screen. Click the <Repair/Compact> button to minimize the size of your data (this should be done at least weekly.) There are two ways to synchronize: Direct and Internet.

If you are going to direct synchronize via a network connection, verify that the target path is the correct path. Preferably, this is a UNC path that begins with "\\". You must be directly connected to your agency network if you are going to synchronize directly. If so, click <Synchronize Direct>. If you attempt to change this path and are prompted about changing the default path, do not change the default path to a literal path such as "C:\Program Files\DF BrokerForce™\Data\Your Replica.mdb". If you are at all unsure, or are not directly connected to the machine with the base replica, you should not change the default path.

If you see the <Synchronize Internet> button, your replica set has web replica hosted on the Internet and you can click this button to send and receive changes via your connection to the Internet. After you have verified that you have an open connection to the Internet, click <Synchronize Internet>.

Due to the nature of partial replicas, some additional policies must be followed. These policies include:

Synchronize frequently (daily) With Internet synchronization, this will typically take less than 5 minutes. The more frequent, the faster it is.

The office should synchronize more frequently. First thing in the morning, at noon and before leaving would be a good schedule for the office. Whenever you open BrokerForce™ and are using a replica, it's always best to synchronize it first. This may not be possible in the field but should still be done daily.

Anyone with a partial replica must verify with the manager of a full replica that a customer is not already in the database prior to adding a new customer.

Data entry responsibilities must be portioned. Reps can enter new orders with line item details. After the order has been submitted to the vendor, this information must be propagated to the central office by synchronizing and no changes are to be made to the order other than by the central office. Orders can only be deleted by the office (full replica).
Otherwise, send the office an e-mail request to delete any unneeded orders. Adding products should only be done by the office. You can add an item to an order in a partial replica even if it's not in the product list, but when you are prompted to add a new product to the list of available products, click <No>.

What partial replica's (reps) can/can't do

They can add orders, customer, contacts, and products (on the product form only).
They can not change the agency wide information for "My Company Setup"
Access to accounting information is limited
Can not delete orders or customers. To delete an order or customer, set the status to "Delete" so that your agency office can delete the record.

Can't synchronize?

"3676 Failure to write to an Internet handle" - Microsoft Access does not see an adequate connection to the Internet for synchronizing. To resolve this, try restarting your computer, use Microsoft Internet Explorer to browse to a web site before retrying the synchronization. An improperly configured firewall can also cause this. If you were prompted by your firewall that BrokerForce™ was trying to communicate through it and you answered <No> to not allow it, then you must read that documentation and allow BrokerForce™ to use the connection.
"No common entry point..." - Your data will need to be replaced, it is either damaged by an unexpected shutdown of the computer while BrokerForce™ was open, or it has not been synchronized within the retention period (usually 60 days).
You need your data replaced - If you have orders or data that is in your data set but has not been synchronized, you may need to upload it to BrokerForce™ for the staff to attempt to synchronize it or append this information into the central database. Their is no assurance that this can be done and you should stop entering data into your data set until you receive a new data set. Use this link to request a new data set.

This page is designed to supplement your company's software support for BrokerForce™ Enterprise. If you need additional assistance, please contact DataForce by e-mail anytime at support@BrokerForce™.com or 303-665-2344 between 7:00 AM and 6:00 PM MST M-F.

Return to FAQs

Home Order BrokerForce™ FAQs Data Request Download Demos Support Contact