Lack of Documentation and Incorrect Documentation etc Makes Many Packages Impossible to Use Properly

Feedback Integration Service
1

So, I’m having a frustrating time trying to get the Slack activities to work.
As is a trend I find in the integration services in particular, the documentation is really really bad and to a level I don’t think should be acceptable for a GA product. I’m also surprised by some of the Ux choices.

I’ll cite some specific examples with the Slack one.

You can send a message, which is straightforward enough on the face of it, and even has a page for documentation. However the documentation is outright wrong, again…

Lets start with the ‘Message Fields’

  • Message fields - Enter field/values in the following format: field1:value;field2:value. These fields are displayed below the main section text in a two-column format. You can also enter variables such as ID, name, event trigger output etc. This field supports String type input.

This is incorrect, if you enter exactly what they say in the documentation you should expect a one row table with two columns, both saying ‘value’ in each column, or if you did field1:foo;field2:boor you should expect two columns, one saying foo, one saying bar right?

Thats not what you get. You get a table with two rows, with the first column saying field1 and field2 in the rows, and the values being in column 2…
So. The Documentation is simply wrong. This is in relative terms a more minor issue as at least the code works so you can correct it yourself…

The worse part of this page is documenting the ‘Button Actions’

  • Buttons actions - Button action properties in comma-separated format: action ID (required), action name (required), style (primary/danger), confirmation title, confirm ok title, confirm deny title. A maximum of five button actions separated by ; can be provided. For example: action1,Approve,primary;action2,Reject,danger;Confirm,Sure?,Yes,No. All action properties (except style) are customer/user defined. Action names IDs must be unique among buttons. Confirmation title, text, ok title, deny title must be used together. This field supports String type input.

If you directly try the specific example given it won’t work. The schema for this csv monstrosity is not explained. I had to guess and do trial and error to get something to work, with the help of a GPT that knew what the options could be for the buttons via the slack API.

This is awful… not only is the documentation just wrong, but the Ux here is so bad. Why is there a string argument here where I need to pass a CSV type thing, guessing the syntax along the way…
I dont understand why we arent using all the new features to allow dynamic data types or something here to give an easy interface to add the buttons. Or even making a wizard to create them which means we can build them in a low code way…

Thing is, once you even get the button to work (at least far enough so they can appear on the message) you’d likely want to be able to have the automation react on one of the buttons being clicked right…?

That takes me to the activity for ‘Wait for an Event on Slack and Resume’
This one is NOT documented, instead pointing to a generic page of wait events in the integration service (better than many which just direct you to the landing page for integration service help).

Its rather limited, with the only event type to wait for being a button clicked.
But again, we are back to guessing how to do this… there are some filters on it referencing actions and message fields etc, but I have no reference of how to link that back to the button I made in the weird CSV format in the last message.
Whats worse, I cannot debug it at all. If I run it then it just gets ignored in Studio, both in run and debug mode it gives the same warning and skips the activity…
Again, this is awful Ux, am I supposed to publish ‘dummy’ automation’s to figure out how the thing even works and then add it to a project, then being unable to actually test the project properly in Studio ever again…?

These sort of things should not get past any QA checks.
They NEED documentation pages that are accurate and explain how to use them, it cannot be considered a nice to have. In my opinion, if you don’t have time to write your documentation, your product is NOT ready for release. All it does is frustrate users as I am here and prevent them from trying to bother to use those products :confused:

I have really really tried to use the Integration Service well, but I feel I come away so many times feeling frustrated like this and not able to do what I need despite it seeming possible without a huge time investment.

A software interface showing a Slack event handling configuration, with a debug warning message in the output panel. (Captioned by AI)
A software interface showing a Slack event handling configuration, with a debug warning message in the output panel. (Captioned by AI)1025×633 24.2 KB

1 Like
2

Please check the Integration service for Slack. I hope it helps.

3

I specifically referenced that same documentation and described how its incomplete and wrong. I do not see how directing me to the same documentation but the home page of it will help at all?

4

To add to this example, the Teams Integration is also just not documented properly and buggy / missing features to make it useful.

For example,
If you look at the Send Individual Chat Message activity, if you right click on the activity and press help you are directed to

https://docs.uipath.com/en/activities/other/latest/integration-service/uipath-microsoft-teams-Send-Individual-Chat-Message

This link doesn’t work, and so it redirects you to a fallback page, which is the generic integration services page.
This is pretty bad, since a documentation page DOES exist for that activity here but the URL doesnt match…

https://docs.uipath.com/activities/other/latest/integration-service/uipath-microsoft-teams-create-one-on-one-chat

The content of this page is still wrong / incomplete though…
One of the arguments in the activity is simply not documented, the ‘Adaptive Card JSON’.
At least that ones easy to use since the adaptive card JSON is at least well documented…

If I then look at the ‘Wait for an Event on Microsoft Teams and Resume’ if I look at the option for waiting for a new message in an individual chat, for some reason its been set so the Chat ID is a property, and not an InArgument, meaning I have no choice but to hard code the value… which just removes any utility for that wait event as it has to be hard coded for an individual user…

I think I have been trying to raise the flag for at least a year now on how the Integration service has soo much potential, but keeps failing cause its at 90% and missing the key features and the documentation is perhaps the worst I have seen at UiPath. The basics need to be improved in my opinion.

5

One of the biggest issues I have with the documentation overall is that they give brief explanations of what each property is (which is typically just the same as what you see when you mouse over it in Studio) and don’t give any details about the HOW or WHY, nor do they give any examples of usage.

1 Like
6

Yeah, but as I have shown they are often not even accurately documenting the properties. Sometimes they miss them, sometimes they reference properties that don’t actually exist, sometimes they reference them but describe them incorrectly.
Its so inconsistent you can never even trust them.

I really feel like they need to invest in some AI validation of their documentation, start simple by just checking, is each property even documented so they know how much to fix, then what properties are documented but actually not real, and then do the descriptions between studio and the documentation make any sense.

That alone could help alot.

They can also do a check like this to see how many Help links are broken like I said based on the example above.

They should make themselves an agent to do this.

2 Likes