CRM.pad is the existing ACRM interface for use with Apple iPad and which is offered as an App available on the App Store. In this article, we explore some of the most common issues experienced by users when trying to use the app, and how they can be resolved.
Troubleshooting steps for CRM.pad.
1. Enabling the logs
Just like any other elements in ACRM, CRM.pad generates logs that Support can use in attempting to identify what is causing a certain issue. The logs specific to CRM.pad are detailed in the manual page on Log Files.
Since CRM.pad acts as an interface with the core ACRM modules, it may also be useful to configure logging for the server as described in Server Log. Logging for the core is further discussed in How to configure logging for the Core and Logs and Error Messages.
2. Is ACRM reachable?
One of the first things that should be tested is whether ACRM itself is reachable from the affected iPad on the web browser, using the same credentials. If it is not, all troubleshooting efforts should be directed to resolving this issue. You may consider contacting your Systems department to resolve this issue, or raising a Support ticket for a deeper investigation.
There are many root causes that could be preventing a connection from being established with the ACRM server, such as a VPN, wrong credentials, etc. Please refer to CRM.Web - Troubleshooting Article.
3. Has the latest CRM.pad version been installed?
Before proceeding with further troubleshooting, please ensure that the CRM.pad app experiencing the issue is up to date. You can always obtain the latest release of the CRM.pad app in the App Store.
4. Is the connection string being refused?
If the connection string is being refused on Safari and the server fails to register on the CRM.pad App, please ensure that the Connection string being provided has been correctly formatted:
<NAME>can be the same.
<IDENT>is CRM.pad's internal ID of the server and
<NAME>contains the name displayed in the login mask.
<URL>contains the server's base URL, usually identical with the Aurea CRM web installation.
<AuthenticationType>defines how the Mobile Services server connects to the Aurea CRM web server (
revolution), see Authentication.
- You can also specify the user agent when registering your server. Add the
userAgentparameter to the URL, e. g.
- If you are using MobileIron Sentry, then set the
truein the URL to ensure that you are able to connect to the CRM Server. For example,
enablemobileiron=true. For more details, see MobileIron integration with CRM.pad application.
5. Does the affected user have a CRM.pad designer configuration assigned?
Another reason why the system may fail to launch is that the user credentials being input are not associated with a CRM.designer configuration for CRM.pad. Depending on the specific issue, you may consider testing with a different designer configuration that works for a different user, as the specific configuration could be to blame for the problem experienced. Note that resetting user credentials has been known to solve related issues in the past.
6. Is synchronization timing out?
If synchronization is crashing after a while, there is a chance that the timeout value set for the module is too low to allow for a full run. The
ClientRequestTimeout value in the web.config file can be increased to allow for a longer synchronization process, which may be required to troubleshoot a certain issue, even if the root cause were to be finally determined to lie elsewhere.
7. Troubleshooting CRM.pad
If you have reached this point without any progress, the next step will be to begin deeper troubleshooting. If you haven't already, this is the time to raise a support ticket, so that our agents may assist you in resolving your issue. As always, any information you may provide for the related issue will assist us in reaching a solution as quickly as possible. Some examples of useful information are the following:
- Screenshots and recordings of the observed errors, if any.
- A timeline of the issue, as well as which users or use cases are affected.
- CRM.pad logs for the time when the issue arose.
- A backup of your CRM.designer database, along with information about the designer configuration that is causing the issue, if any. Note that, depending on how much the environment has been modified, or if the issue is associated with a different module (such as CRM.win Rights), a full backup of the ACRM DB could be required.
- Any other information that you consider may be relevant, like a non-standard architecture, a different method for authentication than the default being used, etc.
To troubleshoot a customer issue with CRM.pad, you may need to directly modify elements from CRM.designer and the Win module. To do so, you will need to connect with CRM.pad to any QA Portal environment that you have access to, as explained in Connecting to ACRM using CRM.pad.
Note that minor issues, or those that do not require deeper modifications can be directly tested in the CRMPAD ENVDS file environments.