Check you have access to the proper domain of the target table

If you don't see records showing up in the target table (such as incident), check that you have access to the proper domain of the table. The records may be saved into a domain that you do not have access to.

Check your dynamic share's business rule is in the proper domain.

When a dynamic share is saved, the business rule it creates is saved in the domain that you are currently in. Check to verify this is the proper domain to ensure that the business rule is triggered when a record in the table to be eBonded (such as incident) is created or updated.

Check the outbound table

First check the outbound message table and see if any siam messages are being sent out. Inserting or updating a ticket will immediately create an outbound message. Messages are responsible for getting the ticket to MBS and ultimately to Remedy. A way to check if an outbound message is created is clicking into the message form and using the “Decrypt Value” related link to see if the data matches your ticket.

If there is no outbound message there might be a few solutions. First check the dynamic share to see if there are any conditions preventing the message being created that you did not know about or do not want. Another quick solution is clicking the related link “Reset Dynamic Share Rules”.

This will make sure the business rule is up and running. Another check you can do is making sure the “Perspectium Replicate” business rule exists, is in the correct domain and does not have any extra conditions.

Check the outbound table

Double check the outbound table to ensure all the mappings are correct. Some malformed mappings can cause the message failing to post to Remedy.

Ensure sending to the correct form

Next check if the outbound message is sending to the correct form. Open the outbound message that corresponds to the ticket and look at the “Attributes” field. If you find that it is sending to the incorrect form, go to the outbound table map and ensure that the attribute “RemedyAPIForm” is correct.

Check the inbound table

Check the inbound table to see if there is any messages from MBS to give you any extra information about what went wrong.

Check the outbound table

Find messages named “common_query” and check to make sure the query looks correct. Things to look for in the attributes field:

• Correct form in the attribute “RemedyAPIForm”

• Correct query time in the attribute “query_time”

• Attribute “remedy_query_string” has a valid query string

• Attribute “query_field” is the correct time/date field to query off of

• Attribute “ SIAM_provider” is “remedy”

If any of these attributes are incorrect go to the Scheduled Job that is sending those messages and make the corrections.

Check the agent logs

Next check the agent logs for any extra information. The agent will print out what url it is trying to query to as well as the response it get back from Remedy. This can provide a lot of useful details about what went wrong and how to fix it.

Check the inbound table and import set

Sometimes messages successfully get queried and are sitting in the inbound table in ServiceNow ready to be picked up. The transform map may have a condition that ignore the message or some other internal error could have occurred. Ensure that there is not extra conditions that cause the import table to skip the message.

Check the agent logs

First check the agent logs for any extra information. The agent will print out what url it is trying to post/query to as well as the response it get back from Remedy. This can provide a lot of useful details about what went wrong and how to fix it.

If there is no logs about attachments being picked up from Remedy you should check that there are query messages being sent to the attachment form.