<mapping>::==<format_prefix><header_prefix><system1_API_name><delimiter><system2_API_name_or_value>

<format_prefix>::==”!”|”#”|”~”|””

“!” – date fields

“#” – number/currency fields

“~” – not nullable text fields

“” – no format_prefix – regular text fields

<header_prefix>::==”.”|””

“.” – applicable only for transactions objects for mapping starting from the second mapping; must be used for the fields from transaction header

“” – no header_prefix – must be always used for the first mapping in transactional mappings and for all non-transactional mappings; first transactional mapping always  used for the fields from transaction header; subsequent transaction mappings (starting from the second one) without header_prefix are used for the fields from transaction line item

<system1_API_name> – API name of the field from the system 1, which credentials are specified in the lines #1 – #5 on the last page of the Company Profile

<system2_API_name_value> – API name of the field from the system 2, which credentials are specified in the lines starting from #6 on the last page of the Company Profile,  or value (in case of the usage of the equal sign as a delimiter)

<delimiter>::==”/”|”\”|”:”|”=”

“/” – unidirectional mapping from system 1 to system 2

“\” – unidirectional mapping from system 2 to system 1

“:” – bidirectional mapping between system 1 and system 2

“=” – setting a static string value for the field of system 1

Note: not all cases are supported for all types of objects and all types of Interweave licenses.. If mapping is not supported please check with Interweave customer support.

Examples:

!Due_Date__c:DueDate – bidirectional mapping of the header field Due Date (date type) in the first mapping for some transaction.

!.Due_Date__c/DueDate – unidirectional mapping from the system 1 (e.g. Salesforce) to system 2 (e.g. QuickBooks) of the header field Due Date (Date type) in the second or subsequent mapping for some transaction

#Special_Cost__c\InvoiceLineCustomFieldCost1 – unidirectional mapping from the system 2 (e.g. QuickBooks) to system 1 (e.g. Salesforce) of the line item field Special Cost (currency type) in the second or subsequent mapping for some transaction

1. Login in to your InterWeave Integration Manager (Flows Manager) using username and password you have (see #1 in InterWeave Integration Flows)
2. Stop all Scheduled flows (see #2 in Working with Flows), and wait until they turn all white (State = Stopped) (see #5 in Working with Flows)
3. Login to QB server and make sure QB file is not open by integration user interweaveQR (you can manually log this user out from the file if all flows are in Stopped State but the user did not log out automatically)
4. Switch QB file onto single user mode, and perform required tasks
5. Switch QB file back onto multi user mode
6. Log in to the Flows Manager and restart scheduled flows (see #1 in Working with Flows)

There are several methods for moving changes from a Sandbox environment to a Production environment, and the best method depends on the nature of the changes and the type of software you are using.

Here are some common methods:

Change Sets: If you are using Salesforce, you can use Change Sets to move customizations, configurations, and data from a Sandbox environment to a Production environment. Change Sets are a collection of metadata components that you can package together and deploy to another Salesforce org.

Metadata API: If you are using Salesforce, you can also use the Metadata API to move changes from a Sandbox environment to a Production environment. The Metadata API is a set of APIs that allow you to retrieve, deploy, create, update, or delete customizations for your Salesforce org.

Version Control Systems: If you are using version control systems like Git, you can version your code in a Sandbox environment and then merge it with the Production environment using a pull request.

Manual Deployment: You can also manually deploy changes by copying the files from the Sandbox environment to the Production environment. However, this method is not recommended because it can be error-prone and time-consuming.

It’s important to thoroughly test changes in the Sandbox environment before deploying them to Production to minimize the risk of negatively impacting Production data or functionality. Additionally, it’s also a good idea to have a backup of the Production environment before making any changes.

Steps

The steps to move changes from Sandbox to Production in Salesforce:

1. Prepare the Sandbox: Make sure that your changes are thoroughly tested and ready to be deployed in the production environment.
2. Export the Changes: Go to the Setup menu, then select Deploy and Export the changes from the Sandbox. This will create a .zip file containing all the changes you have made.
3. Import the Changes: Go to the Setup menu in the production environment, select Deploy and Import the changes from the .zip file you exported from the Sandbox.
4. Review the Changes: Salesforce will show you a summary of all the changes that will be made in production. Review the changes and make sure everything is correct before proceeding.
5. Deploy the Changes: Click the Deploy button to move the changes from the Sandbox to production. You may need to schedule the deployment to take place at a specific time, or you can deploy immediately.
6. Monitor the Deployment: Salesforce will display the status of the deployment process, and you can monitor the progress of the deployment.
7. Verify the Deployment: Once the deployment is complete, verify that all the changes have been made correctly in the production environment.

Note: Always have a backup of your data in case of any unexpected errors.

Referrals:

https://developer.salesforce.com/forums/?id=9062I000000ILcUQAW

https://help.salesforce.com/s/articleView?id=sf.changesets.htm&type=5

https://youtu.be/jcBRFpzTdAY

Below is an example of a IW Transaction Flow Daily Log report for 2022-05-31. This is a once a day file; It’s a collection of logs.

As the customer receives error emails in real time, when your Solution Flow is running. If you need more information, you can reference the log using time stamp as the search criteria. Go to Edit/Find and enter the time stamp.

When the file is sent you to via email (this is if you selected it in your Solution Configuration), you can open it with Wordpad or Notepad (it is in .erl format).

The log format is for the Integration Administrator, who is trained during the Integration process.

1. Stop all scheduled flows.
2. Set the Shift value (column in the middle of the table) to 0. Please remember the original Shift value.
3. Start the flow.
4. After it finishes – stop the flow and reset the Shift back to the original value.
5. Start all Scheduled flows.

1. the quality and amount of your data, duplicates, special characters, loading historical data, etc., and the number of flows you have selected.
2. As we have over 100 flows and 300 configurable options to choose from, we recommend a phased approach so you may manage expectations.

1. Basic Integration. Accounts to Customers, Opportunities to Invoices and Products to Items.
2. Advanced Integration 1. Additional flows (Opportunities to Sales Orders, Receipts, Estimates, etc.).
3. Advanced Integration 2. Account to Vendors, Opportunities to Purchase Orders.
4. Additional files. Add and integrate multiple QuickBooks Company files.

To avoid unnecessary processing of the same records in bi-directional sync we use a mechanism called Repetition Protection. All records, which are last updated in your CRM by the CRM User that is specified in the company profile, are skipped when querying your CRM for the records ready to be processed. This mechanism is included into scheduled flows and bulk load utility flows. It is not applicable if integration is unidirectional or the operations from your Financial Application to your CRM are set to None.