Error: You may face an issue in Scribe where the Scribe Services are not starting or are stuck in the Start state and an error pops up after a while as follows: Without the Scribe Services we cannot use either the Console or the Workbench to develop integration maps. Following is the Solution to resolve the above issue. Solution: Right click on the Scribe AdminServer service and select Properties. Select the Log On Tab and click on This account. Browse and select that Windows account which has been setup as the Scribe Service Account. This is generally the same account with which Scribe has been installed on your machine. Follow steps 1, 2 and 3 for the remaining Scribe services as well. Restart your machine. Conclusion: After restarting you should be able to start your services. Make sure you start your Scribe services in a sequential order and you should be able to open your Scribe Console now.

Introduction: There may arise a scenario where after creating a connection to Salesforce, a field that exists in Salesforce isn’t visible in your Scribe Insight DTS. This can happen because of multiple reasons. In this article I have listed down 3 of the most likely reasons why your SFDC field is not visible in Scribe Insight. Three Probable Reasons: Reason 1 The first reason can be that a custom field was created in your SFDC after you had created your SFDC connection in Scribe Insight. To fix this follow the steps mentioned below: Go to Connections in your DTS Select your SFDC connection Select Edit -> DTS Connection Settings -> Adapter Settings and click on Refresh Metadata. Your custom field should now be visible. Reason 2 The second reason can be that the field-level security has the visibility disabled for that field. To fix this follow the steps mentioned below: Log into SFDC classic and select Setup Go to Build -> Customize -> Object (Eg. Accounts, Asset) -> Fields Click on the field that isn’t visible in Scribe Insight and select Set Field-Level Security Make sure the field is visible for your Profile Reason 3 The third reason can be that you are just using an old API of Salesforce and that field did not exist for that version of SFDC. For example the Asset RecordTypeId field was added in the later versions of Salesforce. To fix this follow the steps mentioned below: Go to Connections Select your SFDC connection and click on Edit Select Change Connection Update the version of the Salesforce URL to the latest version that your SFDC supports

Introduction: If we need to look up for any value from AX then we do it by using a Find Block in Scribe Insight Eg: BasicHttpBinding_ItemService_find Every Find block has 2 components and they are, Query Criteria – Used for specifying the Table Name, Field Name and the Fields Value for finding the record Return Value – Used to fetch the needed value back If for any reason either of the component is missing, then you cannot lookup in AX and search the required value back. Consider the following Scenario where we have a SalesOrderService Find block with only the Query Criteria component but without the Return Value component. Following are the steps to resolve the issue. Steps: Go to your AX Web Service Connection and click on Edit Click on change connection Proceed further by clicking OK and then click on your connection and click on Edit Select the Configuration Tab on top Select the Find Block under Method that is not showing the required Return Value. Here that would be the BasicHttpBinding_SalesOrderService_find Method. Make sure that the value of QueryCriteria_CriteriaElement and ReturnValue_SalesTable both are 1. Note: If you want to look up with additional parameters then increase the QueryCriteria value. Validate your Web Service Connection and restart your DTS Your issue should be resolved and the Return Values should be visible Conclusion Now you should successfully be able to look up and find a value from any of the Return Values in the Sales Order successfully.

This blog is an effort to note down the mistakes made and lessons learned after couple of data migrations completed successfully for our clients. If you are moving from CRM on premise or any platform to CRM Online, you will need to migrate your data. First, determine which entities are being used and needs to be migrated. The order of migration is important as field(s) of an entity can be related to other entity and used on the entity(s) form. Some of the points to consider while migration: Unique identifier in CRM To uniquely identify a record in CRM, use the guid of the record Mapping GUID of the source to target helps in identifying records in source & target Created On date Created date of source record can be mapped to overridecreatedon field in target It can only be inserted once, cannot be modified on update of records Calculated fields Avoid mapping calculated fields to avoid data mismatch during migration. CRM will automatically calculate them on data load of other fields used in calculation Users There are chances that users in your system who have been deactivated own records, such as activities. For assigning a record to any user, the user must be active So if you have a former employee and you want to import activities and assign them to that user, you will need to temporarily have his user record active in the new system. This means creating records for users who are no longer in the organization You can create users without sending an invitation to that address Assign records to the user and then disable that user record Opportunities When importing opportunities, the actualclosedate will be set to today’s date even if you try to load another date to that field. The recommendation is after you update the status of the closed opportunities to Closed, run an update for opportunities updating the actualclosedate to the correct date Activities Individual activity entities like email, appointment, phone call or task should be migrated individually Initially, keep the status of all activities ‘Open’. Once you update all fields and parties of the activities, close them at the end of the migration since once closed those activities cannot be updated If the owner of the account/contact/lead associated with the activities is updated, it may change the owner of activities. To avoid this, either disable parental to cascading relationship (CRM setting) or do not map the owner of the parent on update Always try to run activities in batches as there can be lots of data if your system is too old Activity parties Consider partytypecode and activitytypecode in field properties. If ispartydeleted = -1 that means party associated with the activity is deleted. Hence cannot be migrated If one of the recipients is not in CRM as a contact, account, or user, it will create an activity party not linked to any partyid in CRM. These records cannot be imported Set up your activityparty dts source query to  inner join activitypointer to filter out any activityparties linked to an activity that was deleted from the system This will cut the list down and save much time Connections Connection roles & Association should be present Select record types ‘All’ (not a specific record type) to avoid mismatch. Connection creates its own connection so there are 2 connection records created while migration. To avoid duplicates, Handle in CRM to delete the duplicates based on connection 1-role 1 & connection 2-role 2 combinationOR Design a package to delete the duplicate records if it is already created once Keeping these best practices in mind, you can quickly migrate your data in CRM Online.

Key Technologies: CRM Online, Scribe Insight Note: This article assumes understanding of CRM Online entities and relationships. Knowledge of Scribe insight tool for data integration. For more information on Scribe Insight refer https://www.cloudfronts.in/scribe-integrationsmigrations/ Connections can be used to define the relation between the two entities. You can have an account related to any contacts. With the help of connection you can define that one of the contact is actually the employee in the company and another an employer. 1. Before connections, you should have connection roles and association between the roles defined. 2. Connection Roles A role should have a role category. Consider, a role ‘Client’ which is part of ‘Business’ category, ‘Sibling’ which is under ‘Family’ category. 3. Connection Role Association After defining a role, we should associate different roles. This entity stores guid of the main role and the associated role. Role ‘Client’ can have other roles associated with it. See below example. 4. Select record type ‘All’ to avoid restriction on any entity. 5. Connections Map the following fields for connections between records of different entities. • Record1id • Record2id • Record1objectTypecode (ex: account) • Record2objectTypecode (ex: contact) • Record1roleid (ex: Client) • Record2roleid (ex: Employee) • Description • Status • Ownerid Below is a sample of a contact with role ‘Client’ connected to another with role ‘Attorney’.