Problem ROVO crerate Issue with Assets Items in Customer Portal

[Ruth Moreno]

I have created a Rovo agent for the customer portal. This agent requests the necessary data to create a ticket.

One of the issues is that it has a mandatory Assets field.

Although we have managed to get it to create the ticket, it does not always do so. When it gives us the ID, it does not create it, but when it appears in the [object Object] field, it does create it.

Is there a way to always get [object Object]? I am attaching all the screenshots so you can understand it better.

Another problem we have is with the privacy pop-up. It turns out that our client is a funeral home, so the chat involves talking about death, cremation, coffins... and of course they can't create tickets if they use these words... What can we do?

[Rebekka Heilmann _viadee_]

Hi @Ruth Moreno - welcome to the Community,

When it gives us the ID, it does not create it, but when it appears in the [object Object] field, it does create it.

I don't quite understand that part. Does Rovo sometimes create a request and sometimes it doesn't? Is the Asset field filled whenever a request is created?

To my knowledge, the "Create request" skill only supports Jira standard fields at the moment and therefore wouldn't be able to fill in asset fields at all. Same goes for any form fields that don't have a Jira field connected to it. Is the behaviour you're seeing consistent with that limitation?

As for the "privacy": Some of those limitations come from the foundation LLMs, some from Atlassian's system prompt. Neither can be adapted by us users. Is it neccesary to talk about death, coffins etc. for these requests? Does it help if they "proclaim" themselves as a funeral home and therefore legitimate to talk about that stuff?

[Ruth Moreno]

Hi @Rebekka Heilmann _viadee_  

thanks for your answer.

If you look at the photographs, one of them returns the corresponding asset ID, which is theoretically correct. The problem is that it does not accept this and only creates the ticket when the same field is set with the condition [object object].

And yes, you are right, it only allows normal fields, but we have created an agent to accept all these fields that are currently not allowed and that are part of our clients' ecosystem, because without this, Rovo is not useful to them.

In answer to your last question, yes, imagine you work in a funeral home, it is legitimate for you to use this vocabulary.

Rovo is very interesting, but we have not yet been able to incorporate it as we would like for our clients, or rather, we cannot incorporate it according to their needs.

[Rebekka Heilmann _viadee_]

Mhm.. still not quite understanding the setup. Is the agent called directly from the Portal? And it sometimes returns the ID, sometimes the object? Or does the Agent run on the created Jira work item *after* initial Request creation? The functionality does differ between those 2 scenarios as it's different skills (Edit Jira work item vs. Create Request)

Either way, if you are seeing inconsistent behaviour, it may be due to the prompt and it needs tweaking. However, that is getting less and less important. So not entirely sure what's happening without the full context.

Don't think you can do something about the privacy/legal filter. It's a very edge use case that interferes with recent adjustments of LLM system prompts after models helping users to end their lifes.

[Ruth Moreno]

We have created a custom agent that allows us to help find information through Confluence from the customer portal, and if it cannot be found, then:
1.- Classify the type of request for which the ticket is to be opened, search for the group and the Request Type.
2.- Rovo collects the entire form and naturally asks the user questions in order to add each answer to a specific field.
3.- For asset fields, we use internal IDs so that we can translate them and add them to the corresponding field. This is where, when it shows us the information collected before creating the ticket, sometimes the ID appears and other times [object Object] appears. The curious thing is that when the ID appears, it is not able to create the ticket, and when [object Object] appears, it does create it.

I hope I have explained myself better :)

[Rebekka Heilmann _viadee_]

So the customer input is mapped to an ID that is mapped to an object... but the last mapping step doesn't always work?

I guess you already tried tweaking the prompt to force Rovo to return the object rather than the ID?

[Ruth Moreno]

Hi,

Well, yes, I don't know if I'm doing it wrong because it doesn't always accept it, which is why sometimes I take the ID and other times the object.
It's very strange...