Integrations - Recent Threads

RE: Send Document as Base64 - SOAP Integration

erickjavidb860617 — Tue, 12 May 2026 16:20:43 GMT

Thank you for your response and for sharing your experience.

I’m going to try the database plugin approach first and evaluate how stable it is in our case. As you mentioned, I’ll make sure to clean up the temporary table after each execution.

If that approach becomes difficult to maintain or introduces performance issues, I’ll probably consider either a custom plugin or an intermediate service to handle the XML/Base64 transformation outside of Appian.

Thanks again for the suggestions.

Send Document as Base64 - SOAP Integration

erickjavidb860617 — Fri, 08 May 2026 23:03:21 GMT

Hello everyone,

I hope you are doing well.

I am currently facing an issue while sending a SOAP request through an Appian Integration. The request body contains a document that must be sent as Base64 inside the XML body.

I have been researching possible solutions, and according to the Appian documentation, automatic Base64 conversion only seems to work when using a Data Type (CDT) with automatic XML conversion enabled.

However, in my case, the XML structure required by the service contains specific namespaces and a custom structure, so when I tried using a CDT, the generated XML did not match the expected format and the service returned a 500 status code.

I also found some plugins that convert documents to Base64, but my requirement is only to convert the document temporarily and send it in the request body. I do not need to store the Base64 value in the database.

Another alternative I considered was creating an Appian Web API that returns the Base64 content and then consuming that response in the Integration. However, the main issue is that Appian does not seem to provide a native way to convert a document to Base64 when building a custom SOAP/XML request manually.

Has anyone faced a similar scenario or found a better approach to send documents as Base64 in a custom SOAP/XML request?

Thank you in advance for your help.

Integration between Salesforce and Appian

Nadia Farooq — Fri, 28 Feb 2020 02:26:52 GMT

can someone please help me out with how i can go about the Connected System integration between Appian and SFDC. I have read through the docs and I have to get key information from the App Manager ini SFDC. My companys SFDC instance does not currently have Appian in the App Manager. How do i go about getting the information that i need such as the consumer key, consumer secret key etc. from the App Manager? Is this something that requires development on the SFDC instance? I dont want to use the WebAPI approach (assuming that the connected system approach that was introduced in 19.2 has better functionality.)

Also, please note that the following link on this page https://docs.appian.com/suite/help/19.4/Connected_System.html#username-password-oauth-authentication points to an expired link in SFDC. Please let me know.

Username-Password OAuth Authentication

Provide a single Salesforce user’s credentials to authenticate. All integrations will use a shared Salesforce username and password. Individual Appian users do not need their own Salesforce accounts.

Please see Salesforce Username-Password OAuth documentation for more details.

Thanks

RE: Integration between Salesforce and Appian

erickaw490332 — Mon, 11 May 2026 09:08:45 GMT

Small navigation mistakes like this can waste more time than expected when searching through version-specific documentation. The explanation about manually switching from Spring v48.0 to Winter 20 v47.0 is actually very useful and easy to follow. I once spent nearly an hour troubleshooting a broken reference link before realizing the version path had changed completely. I would share this fix with teammates during a quick Connections Game discussion break.

RE: Integration between Salesforce and Appian

ferdinandl463254 — Mon, 11 May 2026 01:36:58 GMT

In addition to hygiene and durability, regular cleaning helps protect the financial investment involved in purchasing a TPE sex doll.

RE: Send Document as Base64 - SOAP Integration

Stefan Helzle — Sat, 09 May 2026 09:22:21 GMT

This is a very well known issue. The limited support of separate Base64 conversion is the memory consumption and potential risk of system stability.

All my past experiences with SOAP and Appian have been painful. Mostly caused by the pure chaos of SOAP.

I think that the most direct approach ist that database plugin trick. Just make sure to clean that table after the call.

If this does not work, I suggest a custom plugin. A middleware or API gateway doing translation from/to JSON & XML might also be an alternative.

RE: Integration between Salesforce and Appian

Cornelius — Sat, 09 May 2026 08:57:46 GMT

This realistic sex dolls blends soft-touch materials with artistic craftsmanship to achieve an elegant and natural-looking design.

Built for realism and durability, this premium celebrity sex doll offers exceptional detail, refined beauty, and long-lasting quality.

RE: Transition from Microsoft to Google

Mike Schmitt — Fri, 08 May 2026 19:11:01 GMT

Hey Jamal -

Just FYI, .xlsx is an open (XML based) format, so Excel shouldn't be *strictly* required. If they're wanting the ability to open documents 100% locally, which it sounds like you're saying, it might be worthwhile to suggest that the free office suite LibreOffice has built-in support for Excel files, and therefore should support download-time opening of your report files after only minimal configuration at the individual PC level.

I'm not sure if there's any easy solution that completely bypasses .xlsx hard copies, though I suppose (with quite a bit of extra work) there could be options available through Google Drive integration.

Transition from Microsoft to Google

Jamal Case — Thu, 07 May 2026 16:46:33 GMT

Our client has transitioned from Microsoft to Google Workspace and no longer provides Microsoft licenses, meaning end users can no longer open the .xlsx files generated by our current Excel Tools v2.10 implementation. We need to convert our data export functionality to a format native to Google so users can access their reports without needing Excel. What is the recommended workaround to replace the Excel tools plugin smart service? We are looking for an alternative that avoids physical Excel files entirely to ensure a seamless experience for our users.

RE: Transition from Microsoft to Google

Stefan Helzle — Fri, 08 May 2026 19:01:14 GMT

You might be able to directly create the export spreadsheet file in Google and provide the link to the user.

RE: Transition from Microsoft to Google

Jamal Case — Fri, 08 May 2026 17:30:34 GMT

Currently, our export functionality has a download link of the excel document. In order to open you need to have Microsoft Excel on your machine. I wanted to know what's the alternative for google and best practices for implementing this.

RE: Transition from Microsoft to Google

Stefan Helzle — Fri, 08 May 2026 13:53:06 GMT

I support this. Google Workspace supports Excel files.

RE: Integration between Salesforce and Appian

leonm227368 — Fri, 08 May 2026 08:06:48 GMT

This feels like a setup gap rather than a code problem. Another angle is that Appian integration depends on a properly registered connected app in Salesforce. Quick thought: you likely need admin access to create a Connected App to obtain consumer keys. I once hit this when integrating a CRM, blocked until permissions were granted. Sharing via Slice Master made tracking easier.

RE: Transition from Microsoft to Google

subhankar-Maantic — Fri, 08 May 2026 03:15:12 GMT

As far as I am aware, google workspace fully supports viewing and editing of xlsx files. Can you please check on that. Or CSV could be an option.

RE: Integration between Salesforce and Appian

madisons121697 — Thu, 07 May 2026 02:44:07 GMT

We faced something similar integrating our marketing automation platform with our CRM. It was a Level Devil nightmare of mismatched data fields and conflicting workflows! Ugh, the pain is real. To get Appian into your App Manager, you'll likely need to explore App Exchange packages or custom integrations.

RE: Internal web API Call

almuqeets268991 — Wed, 29 Apr 2026 10:30:25 GMT

This usually happens because external URLs route through DNS, public IP, and network security layers. In many setups, an SMS firewall or network firewall can block or restrict these loopback requests.

localhost works because it bypasses those layers and stays inside the server.

But this isn’t reliable for all environments, especially in cloud or microservices setups.
Best practice: Avoid internal HTTP calls and use direct service communication.

Internal web API Call

simik — Thu, 21 Sep 2023 20:29:57 GMT

Hi,

When I call a web API from another web API within the same server, the external url parameter value of the final web API iin the httppost request doesn't seem to work but I have to give the localhost url - like this :localhost:8080/.../webapiname. Why is that and will this work in all environments? I understand it is not ideal to call this way, but I a little confused as to why the direct url is not working.

My integration object is calling the swagger endpoint multiple times when it is being failed

vijayp6380 — Thu, 23 Apr 2026 11:18:44 GMT

My integration object is calling the swagger endpoint multiple times when it is being failed. We have a log system in our SQL DB. When I test the endpoint from swagger, I am getting only one log but when I am I clicking on Test Request in the integration I am getting multiple logs

RE: My integration object is calling the swagger endpoint multiple times when it is being failed

Shubham Aware — Mon, 27 Apr 2026 12:18:09 GMT

Test Request internally makes multiple calls to the endpoint - one for validation/inspection and one for the actual request.
If you're using OAuth 2.0, an additional retry happens on 401 to refresh the token and re-call.
This is expected behavior.

RE: My integration object is calling the swagger endpoint multiple times when it is being failed

priyadarshinig465 — Sat, 25 Apr 2026 19:30:46 GMT

If only one log is written in the database, the repeated calls are likely failing before they reach the logging logic. The clear solution is to check API server logs to trace all incoming requests, review Appian integration timeout/error settings, and fix the failure point causing retries. Also move the logging step to the start of the API flow so every request attempt gets captured.

RE: My integration object is calling the swagger endpoint multiple times when it is being failed

Stefan Helzle — Thu, 23 Apr 2026 13:59:48 GMT

Yeah, Appian might try a different authentication method.

RE: My integration object is calling the swagger endpoint multiple times when it is being failed

vijayp6380 — Thu, 23 Apr 2026 12:49:28 GMT

when the swagger endpoint returns status code as 401, then I am getting multiple logs when I click Test request from Integration

RE: My integration object is calling the swagger endpoint multiple times when it is being failed

Stefan Helzle — Thu, 23 Apr 2026 12:09:19 GMT

[quote userid="258542" url="~/discussions/f/integrations/40363/my-integration-object-is-calling-the-swagger-endpoint-multiple-times-when-it-is-being-failed"]when it is being failed[/quote]

What is failing? Appian does automatic retry in certain situations.

RE: Docusign fail return of Oauth

Carmine Mele — Wed, 22 Apr 2026 12:45:31 GMT

Thankyou for tour answer but as a precaution, I deleted all the connected system versions I had previously created and rebuilt a DocuSign connected system from scratch, using an unambiguous name to avoid any confusion.
I verified all the keys, and even before that I had been using only the connected system obtained from the interface check, which was failing due to the absence of a valid token. Unfortunately, this did not change anything.
I did not choose the JWT authentication method because it is significantly more complex to manage and, in theory, it would not guarantee the actual presence of the person who signs.

Docusign fail return of Oauth

Carmine Mele — Tue, 21 Apr 2026 06:10:50 GMT

We are using a DocuSign integration configured and tested successfully in the development environment with a DocuSign developer account.

However, we are encountering issues during the authorization phase when using the authorization link.

The authorization flow redirects correctly to DocuSign, and the login page is displayed, allowing the user to log in successfully. However, after the login, the system does not return the authorization token to the application as expected.

By checking the application logs, we can see the following error during the OAuth callback processing. This error appears multiple times; below is one example:

2026-04-21 05:57:39,619 [http-nio-8080-exec-794] ERROR com.appiancorp.connectedsystems.http.oauth.OAuthServlet - Error processing request to Appian OAuth callback URL. 
com.appiancorp.suiteapi.common.exceptions.AppianException: Failed to decrypt. Only values of type Encrypted Text can be decrypted. (APNX-1-4260-002)

It seems that the OAuth callback is reached, but the token exchange or decryption step is failing.

I'm trying to recreate connected system or new keys on docusing, but without success.

The AUTHORIZE button in the connected system, go, but we have multiple singers and we have to use authorization link in interface