1 - That works. 2 - No, they do not. It will write them to whatever dataset you instruct it to. 3 - You could have a function make a UUID and then include it in what you pass to the dataset. You can also grab metadata from the workflow, such as who started the workflow and include it in what you write to the dataset.

Here's a screenshot if the inputs

Here's the function.

So it's a statement. I'll make sure engineering sees this. If you have any questions, let me know.

Last thing I will say, is that AppDB is often easier for things that you might want to update. So if you're capturing these and logging them to exist forever more, an append to a dataset is great. If you want to update those values later, LMK and we can talk about AppDB.

Typically folks will you use the string builder to create their list of values. You can select CUSTOM and then insert variables. {{variable1}} | {{variable2}} | {{variable3}} Then pass a pipe as the delimiter. Hopefully that makes sense.

Append to dataset looks for a delimiter, a dataset and values. The dataset is what you want to append to. The values is a list of values to write to a dataset. If your dataset has 5 columns, you need to write 5 values. The delimter is to allow you to stipulate what seperates your values. Comma is default, but sometimes…

Is there a question I’m missing here, or is this just a general statement?

John, sorry you’re so frustrated. I agree with you that it should be easier to see the user who completed a task. I have two solutions for you. 1 - I can share a function you can run right after your user task that will tell you. 2 - there’s a DomoStats report that is either available now, or very soon (need to double…

It looks like something is expecting a response that it is not getting. I'd open a ticket with support, and share that TOE. I will see if I can get someone from Domo Engineering to look at this for you.

I replied to your other thread on the same topic.

Create the workflow that has date, line, crew id, type and duration as inputs. Have the workflow include a user task that prompts for a reason. Create an alert and tie an alert action to start the workflow. If you go through the "Getting Started with Workflows" training at learndomo.domo.com then it covers off on all of…

Yeah, we could process and parse images from S3, SFTP, etc… We've also got some new stuff getting announced tomorrow that will be an unlock here…

John, you can put HTML in the body and it will render it wonderfully. As far as the attachment goes, that’s the FileID for a document stored in our FilesAPI. The FilesAPI is well documented at developer.domo.com. The use of it in this function is not, and I apologize. If you have a form that includes an attachment, what’s…

Beau, codeEngine doesn't support "PATCH" at this time, and the PRODUCT api end point to update parameters on user profiles leverages a patch. That said, the OAuth API will update a user leveraging a PUT, which codeEngine supports. I know of customers who have used this to accomplish what you're after:…

Nate - thanks for sharing your experience. I will make sure that engineering sees this.

I'm not exactly clear on what you're trying to do. You shouldn't need to do any authentication. Are you trying to add a user to a group? And you have that users ID stored in a person variable in your workflow?

The add user to group is an Okta function to add someone to a group in Okta. The others are for Domo Groups.

Are you saying the status variable was updated by the "Get Dataflow Execution Status" step? Can you post a screenshot of what shows up for the inputs and outputs for that step, please?

Send me a PM.

I'm not sure that I follow, but if you go to the Asset Library, then in the upper right go to Pro Code Editor, the Workflow Start Form is there. It's well commented with good examples, but you'll need some JS/HTML/CSS skills or help from an AI as you're in pro-code territory. If you need to embed it, that's what I would…

Workflow start forms, unfortunately, don't work in Embed at present. The work around currently would be to build a brick that is the workflow start form. That will work. I will make sure engineering sees this.

Yeah - upsert is awesome, but comes with it's own set of challenges/caveats. AppDB provides more flexibility for edits, but if you haven't used it before can be daunting/intimidating. I'm glad you got it up and running the way you want.

Nate, how did you get on?

Jaden was quick in the response, thank you Jaden! John, thanks for backing up my feedback to the team that this should be a "system variable" that just exists for every workflow…who started it, what time, how, etc…

No matter what, responses will be tracked at the individual level, by the way. The metadata will always show which user actioned/completed the task.

Nate - I’ve had customers take the approach of dynamically creating the group, adding the users, sharing the queue, then deleting the group and so on. I have a function I can share with you, that will allow you to programmatically share a queue. Here’s another thought. Could you make a dynamic group with a rule that…

The approach that I personally would likely take, is writing this new data (application decision) to AppDB and joining it back to your source data in a VIEW (no processing time and no credits used in the join), and then materialize it back to the source data on infrequent schedule.

I know the product team is working hard on some of these data update features…maybe we will see something at Domopalooza? I do lots of these things with AppDB. The way that update a row works, is by defining an UPSERT key (which is a unique identifier for each row, and typically a combination of columns) and then sending a…

I agree with you that documentation could be improved, and we could have more videos. Please keep the feedback coming - the videos which I created were a result of things I recognized and feedback I heard from customers, and I'm happy to make more. I'm also happy to pass feedback along to the product and education teams.