How to Build Low-Code/No-Code Apps with Fusion Data API

Welcome to this class. The topic today is how to build low-code, no-code apps with Fusion Data API. Now the objective of the class is to learn what the manufacturing data model can do learn, what low code no code technologies are, and how to use them, learn the limits of low code no code solutions, and get ideas for your business on how you can connect the Autodesk platform with your enterprise systems. So why did I choose this class?

Well here at coolOrange, we want to reduce complexity. We are thoughtful developers nerds but we like to reduce complexity, and we like to enable potentially everyone to get more out of their software application by enhancing it connecting it, and so on and so forth. My name is Marco Mirandola. I'm Chief Vision Officer here at coolOrange.

coolOrange is a software company focused on connecting design teams with the rest of the company. We have sites in Europe and US, our customers are spread across the whole world. And in the last years, we specifically focused on connecting Volt with ERP systems. So you see at the bottom just a selection of the ERP system that we have connected with. But we're not limited just to that.

I mean it's also PLM and anything else. So everything that belongs to have the design team working fluently with the rest of the companies is where we feel home. So let's get started. And we start by the page from Autodesk, the Autodesk platform services where you find the documentation of all the APIs that are available.

More specifically today, we're going to talk about three APIs, the data management API, the manufacturing data model API, and the Data Exchange API. Now we will spend more time on the middle one, the manufacturing data model API. But I just wanted to show you these three API because they have quite something in common. So you see that all three APIs gives you the ability to navigate through hubs, projects, and folders.

But when you are using Fusion, Fusion Team, or using Beam Docs, or Autodesk Docs, all three APIs allow you to navigate through this API, or through this objects, right? But then there are some differences. So for instance, the data management API gives you more functions around items, around items and versions. The manufacturing data model gives you more abilities around components and structures, manufacturing, or mechanical information.

And the Data Exchange is more focused on exchanging data. So how can you basically exchange CAD model data from one system to another one, and so and so forth? Now, another thing is that the data management API is actually the oldest one if you want. And it has a classic REST API, while the Manufacturing Data Model and the Data Exchange, they use the GraphQL API, which is a little bit more modern API. And we will talk about that during the session.

So what are the classic use cases for these two types of APIs, or for these APIs in general? Well, one use case is to do data integration, so exchange data between systems, whether it's the PLM with the ERP, the CAD with the PLM, the CAD with ERP, or any other system. It doesn't matter, right? And this is something where Microsoft Power Automate may help us, and we will see how.

The second use case is the data interaction, so having the ability to interact with data, to collaborate on data like creating writing, and so on. And usually, it requires a custom UI. So it could be something like generating reports, or getting a subset of data, filtered data, or maybe even contributing with notes and so on. But usually, with specific UI for a specific type of persona with some specific requirements.

And to show you how you can do that, we're going to use the Power Apps, again, from Microsoft. There are other platforms on the market that can do process data integration like Zapier, and if this then that, and all the other stuff. And there are also other platforms for doing custom UI. There is a platform for instance, called retool, which is doing an excellent job. Now, in this case, I choose Microsoft for obvious reason, not because it's the best one or it's the more complete one, but it's the one that basically everyone somehow heard about it, or knows about it, maybe has even available in the company and so on.

So what is low-code and no-code? Well, before we answer that question, let me erase one question. I'm a nerd. I love coding. So why should I code less?

Well, there is one thing that applies to me that maybe applies also to other developers worldwide. And typically, developers are lazy. And that's a good thing, because over the years, we developed components, objects, libraries that basically reduces the complexity of dealing with code, or dealing with coding overall, right? So back in the days, you were basically using just a text editor for writing your code. And then you were compiling your code with a command line.

Nowadays, you have very fancy user interfaces, which help you with IntelliSense, and now with ChatGPT, or even the new GitHub Copilot, the code is almost written by itself, well, not completely, right? But the fact that we are lazy, it pushed us to think about how can we further reduce complexity. And this is how the platforms basically came along. So another thing is that every line of code, whether you like it or not, might be a source of trouble, source of bugs. So the less code, we write the more existing components and libraries we're using, the less we have the situation where you may run into trouble where we would not expect problems at all.

So what is low-code/no-code? Well, one thing is that usually with low-code/no-code platforms, you expect visual development tools. The second one is that you use pre-built components. Then you have this abstraction of complexity. So you try to hide all the complex thing behind the scene, and then you may have some coding, but it's minimal coding, right?

There is this ability of doing rapid prototyping, and then through iteration quickly come to an end. Obviously, it has to be user-friendly. And it brings a certain level of agility and flexibility to adapt to the changes along the way. The last point, and that's the one that I personally like the most is, the simplicity of deployment and hosting. And we will see that during the session.

So let me show here a scenario. So we are involved. We have a bill of material. We change the state and release it. And by doing so, a bunch of jobs have been queued into the job queue of Vault. So here is the list of jobs.

Well, in parallel, the job processor of Vault is actually already processing all these jobs. And in this case, it's pushing the data from Vault to an ERP system called Microsoft Business Central. And we see here basically how the items have been created.

This is a nice, simple scenario where data from Vault are pushed to the ERP system. The question is, how we can accomplish it. Well, option one is full-code, so run it as a studio. We're not going to do this together, so don't be afraid.

But we have here a screenshot of just an example of Visual Studio with .net code. And we see here all the lines that are required. And by the way, this is not even the whole code. This is just a first draft. I didn't finish the code. It was just to make a point here. So you see Visual Studio. You see the reference, and so on and so forth.

So if we deal with the classic coding environment like Visual Studio, we have to create a class library. We have to select the right .Net framework. Pay attention, because meanwhile, there is the .Net, .Netcore, and the framework, and so on, so it's a little bit confusing. And you have to add the references, the NuGet package, inherit your class from Ijob interface, implement the interface.

Then you have to use the native API for dealing with in this case, Vault and the bill of material, and so on and so forth. And then finally connect through the REST API of Business Central for instance, using REST sharp or any other NuGet package, whatever. And then at the end, you have to compile and deploy. So this is what you typically do. So a bunch of stuff is really just about organizing the work and setting up the environment, and so on and so forth until you can actually go to the coding.

Let me show a different approach. And this is what we have here at coolOrange. So specifically, now for Vault and Inventor, we have created an extension for Microsoft Windows PowerShell so that through PowerShell we can actually communicate with ERP system, we can communicate with the Vault, right? And in this case, you see this black screenshot here. That's the code, that's the script for running the example that we saw before in the video, right? So effectively, that video was done with this script.

So what the script is doing, well, on line 10, it's connecting to the ERP system. On line 12, it's gathering the bill of material from Vault, get Vault item BOM. I think that is obvious, right? And then on line 14, it's looping through the bill of material. And on line 15, it's actually for each BOM row, for each item in the BOM row, it's actually creating the item inside the ERP system. So the point is, that what we did is that we took the complex API from Inventor, from Vault, whatever, right, and we've wrapped it into simple and simplified PowerShell commandlets with intention to allow to anyone that has certain level of scripting skills to actually write his own scripts, and functions, and so and so forth.

Let me show another example here. So let's say we want to add a tab to Vault. So let's close Vault for a second, go into a PowerShell environment. We use these views to the code, doesn't matter, right, create a new script, and then just paste the script. The first line is important, so add Vault tab. That one is doing the magic. The rest one is basically just to coincide the tab to do some action.

Let's restart Vault and let's see what happened. So there you go. We have now a new tab inside of Vault and it's doing something. It's reading the BOM from the file and showing it to me, right? Pretty simple, few clicks, few lines, and we have been able to make a change of the Vault user interface.

Let's do another thing, and let's add a menu item to the Vault. So on a folder, I would like to have a manual item which allows me to queue jobs for all the files in the folder and basically queue a PDF creation job. Here again, first line, add Vault Menu Item. That's the one that makes the magic, right? Let's just restart Vault, go on my folder.

And here we see our new menu item called powerJobs Client. And here's my new menu item. And if I click on it, then basically for all the items, for all the files a job is going to be queued.

Last thing let's, try it also with Inventor. So let's create another script, which is going to create a menu item within Inventor. And in this case, it's going to add a visual component. So here we have Inventor.

And let's open up an assembly, and push the button. So here's the new button that we have. And this basically is going to generate this new virtual component. And we see also the virtual component inside in Inventor.

Now, the funny thing is that we can now change the code while the application is open. So we don't have to recompile or anything, right? We just go here in the script and change for instance, the quantity from 10 to 99. And we just go back in Inventor. We didn't restart it. It's still the same session. We are going to delete this virtual component and now create a new one.

And let's look into the BOM. And we see that the quantity is 99. So just another a little thing that makes the whole life easier. Don't have the need to every time close the application, change the code in Visual Studio, recompile, and restart the application, so you can actually make the changes along the way.

Now, still the question is, is this low-code? Well, the answer is, no, it's not, right? I mean, you saw before the list of points. And let's go through the list quickly. So do we have pre-built components? Well, this is a stretch. I mean, we have common-led Is this really pre-built component? 50%, not really, really fully.

We have an abstraction of complexity. Yes, we have. So dealing with the common-led is way simpler than dealing with the native API. Then we have the rapid prototyping. I think, yes, because it allows me to open up a PowerShell script and quickly go in and tinker and try stuff out and so on. And then in iterative process, finish our job.

Then we have agility and flexibility. Absolutely, as I mentioned before, I can actually make a change on the code while the application is open, so I don't even have to rebuild, and rerecompile, and whatever. And regarding the deployment, well, we introduce something inside in our tools specifically for Vault, which actually deploy the changes to all the clients automatically. We don't have the hosting, but that's because in this case, we are on prem. So we are on the desktop that there is no hosting concept here as well, right?

However, the last three points, we don't have a visual development environment, so we don't have minimal hand-coding. We have still quite some coding. It's definitely less coding than before, but it's still coding, right? And is it user-friendly? I don't know. I don't think that this really applies in this case, right? Every time you have to code something, I don't think that user friendliness is a term that you would apply to it. So the answer is no.

But I wanted to make the point, because again, we try to reduce complexity. And we did it over the years on the desktop side. And now, we basically look into this new technology on the cloud side and see basically how this may work out, OK?

In a couple of slides before, I told you that we have typically, two scenarios, right? One is data integration. The other one is data interaction. Let's talk about data integration.

So we have here an example where we are connecting Fusion 360. So you see on the left hand side this 3D model. And on the right hand side, we have Fusion 360 Manage, the PLM system. And what I want to do is, I want-- whenever I'm going to create a new milestone in Fusion 360, I want to have the bill of material, or the component structure of this model basically shared with my PLM. Let's roll the video and see how this works.

So we go on the Fusion 360 side and make a small change here. We just roll this down a little bit, save it, and we say, OK, this is a milestone. So we hit OK. And if we go now on the Fusion 360 manage side and we refresh it-- we may just wait a few seconds. So let's refresh it, and let's do it again. And still nothing. Oh, there you go.

So here is the main assembly. And now, we also see a couple of components, six pieces. So let's do it one more time. So now, we have seven components. OK, that's good. Let's click on the main assembly. And here, for instance, we see the information, but we also see for instance, the bill of material, right, which effectively reflects the component structure on the Fusion 360 model.

So the question is, how do we do this? So let's reroll the video, the same video, but in this case, we're going to add one component, which is Power Automate. So you see again, Fusion 360 on the top left, Fusion 360 Manage the PLM on the left bottom side. And then on the right hand side, we see Power Automate.

So let's go with Power Automate and set this flow on test, because we want to see what happened behind the scene. Let's make a change again. Let's set a milestone. And now, we see the flow is running in Power Automate. So this is the one that made the magic, right? And now it's done. So if we go in the PLM, we see now the data here again, there you go.

Now, let's give a look into the flow. So first thing is we get data from Fusion 360. And here, we see basically the list of components from my 3D model. Here is the full structure of our so-called JSON payload. We will talk about this later. But this is the data that I get basically from Fusion 360.

Then I have to go into this data and pick out some information, such as the item number and so on and so forth, right? Then we're going to look into the adding the main items, so the top assembly here. And we do this-- so we create here the assembly by using the Fusion 360 data that we received before, and we see here the result.

Now, what we need from this creation is the DMS ID later for creating the bill of material. Now, this is what we're going to again, go through this data and do some manipulation, right? Then we initialize here an array where we're going to store then the bill of material data. And here, we cycle through all the components of my assembly. And again, we create for each component an item in Fusion 360 Manage.

But then again, we have to remember and store the new DMS ID, so the ID that Fusion360 Manage generated for this new item, because we have to add it to our BOM array so that in the last step-- I'm first going to translate this again to JSON. And then in the last step, we are actually going to pass this bill of material back to Fusion360 Manage. So we have been able to collect the component structure from this 3D model and then pass it to Fusion 360 by creating the item and the bill of material without writing a line of code by using a flow.

So how is this all working together? So we have Fusion360 on the left and Fusion360 Manage on the right. And the Fusion360 actually notified us to a so-called webhook. That's a trigger, right? It's an event, or it's called webhook in the cloud, but it's a trigger. So it says, hey milestone reached, do something, right?

And it tells basically the two blue boxes, which is Power Automate from Microsoft, that something happened. And so the blue boxes can now react on this webhook, and then start to flow and start doing something. So what it's done, what it's doing is, we saw it before in the slide, but effectively, it's using the API on the right hand side to talk with Fusion360 Manager, and then create the item and the bill of material, right? So that's a very simple way for showing how this all works.

Now, in the case of Power Automate, we have these two boxes. One is the connector and one is the flow. So let's break it down and let's go more into details. The Power Automate connector, well, we don't have just one connector, or in my case for showing you this examples, I could make it with one connector. I needed to use multiple connectors. And one of the reason is that each connector works with a specific host.

So you see here just the basic information about the connector, but one connector, the host is the developer API, autodesk.com. For the other one is the coolOrange autodeskplm360.net, right? So because I have two different hosts, I need to have two different connectors, OK?

So how can we build a connector? Well, let's do this together. And we go inside Power Automate. We go under Custom connectors side, create a new connector, give a name, in this case, it's test, provide an icon, give a description, and a background color, or whatever. But the most important thing here is the host, so with whom are we going to talk?

Well, let's go on the Autodesk documentation. We have the authentication page here. And on the API reference, for instance, we see here one endpoint. And we just basically grab the host.developer.api.autodesk.com, go back to our connector, enter it here, and then we move forward.

Next step is, we need to authenticate. So he needs basically credentials from us. We're going to use the Oauth2 authentication, right? And for doing so, we have to create an app. Now, if you go back to the documentation, there is a step-by-step tutorial. We're not going through that, right?

But we go on the developer portal and we see here the apps, I'm already logged in. So I see already my apps. And I'm going to create a new app here, also called test. And from the three options, we take the first one, a traditional web app. That's enough. If you want to add details, read the documentation. That's fine.

So we have now some information. We have 13 APIs available, which is quite a lot. Then we have the client ID and the client secret. So let's go back to our connector and enter the client ID, and also take the client secret. Here's a client secret. And now, we need the authorization URL and a token URL. So here on the token, we see the get authorized, and here is the endpoint. So let's take this endpoint here.

And for the token, here we have again the token endpoint, which is also used for doing the refresh. This is a change that recently Autodesk made. There's a version two of this API now. So let's talk about the scope. The scope is which permissions do we want to have, or do we need for accessing the data. And you know, here's the list of permissions. We definitely need the data read. But we may also want to have the data right and the data create.

Then we have the redirect URL that we have to leave blank for now because it created automatically on the save of the connector. But in the next step here, we can create a first action. Now, the first thing that we can do is a very simple. It's sort of a Hello World if you want. It's basically just get the list of the hubs, right? So you may have connected with more hops. I have multiple hops. One of these is the coolOrange hop. But you know, I also have different one.

And here, we have to provide again the endpoint for that hop. So we go back to the documentation, and we look for the data management API. You remember at the beginning we had three APIs, one of which was the data management API. So let's take this one here. And we go to the API reference, and we pick here for instance, the hops API. So to get hop, or to get hops, so I get the list of hops.

So we could take the whole URL, but effectively, we just need the last piece, because if you remember, the connector works with the given host, right? So he knows the host. He just needs basically the endpoint. We're going to say, OK, it's a get operation. We basically enter here the link to our API. And that's it pretty much, so we're good to go. There is nothing else we have to do.

So let's create the connector finally. So save and create the connector. And now, let's try it out. Wait until he's done, OK. So let's go and test and try it out. So we need now to authenticate, right? Oh, problem here, so invalid redirect URL. Well, we haven't provide one because we didn't have one so far. We had to create the connector first so that Microsoft is generating one. We see it now here in the security.

So we can make a copy and now go back to the App inside Autodesk, and add this additional redirect URL here. This way, now the two system can talk to each other, Microsoft to Autodesk, and Autodesk can send back data to Microsoft. And this is the way that the Oauth works, right? So he sends me to the authorization page from Autodesk, right?

Here, I can say yes, allow, or not allow. If I allow that, he sends back the token. And now, with this token I can basically test my GitHub, and I can see here the result of this action, right, so it all works. So this is the way that you can build a connector.

The question is, why do I need to create a connector in the first place? Isn't it there a connector from Autodesk I can use? Well, yes, there is currently one. And this connector is specifically just for the Autodesk Data Exchange API. You remember in the slide, it was that the third one, right? That API is on beta right now, public beta, so you can play with it if you want. And for that API, there is a connector.

Now, what is this connector doing? You see here there are two triggers, right? So you can actually be notified if someone is generating an exchange. So he's basically exporting data from his CAD application to be shared with other people, right?

So you get the notification there. Or if that data is going to be updated, right, then again, you get the notification. So those are basically the two triggers that you get. And then you can do something with it.

Underneath, you see here a couple of templates and examples, right, where you can export data to an Excel spreadsheet, or connect with Teams and inform people that there was a change, or maybe even connect with Trello, and maybe you have a Kanban board that will help you to deal with your product and so on. Or you maybe just exchange the data to SharePoint and then to a CSD field, or a file, and whatever, right?

So these are things that are already available. If you want to play with it, you're welcome to do it, right? But again, for the sake of the thing that I was willing to do in the context of this class, this connector was not extensive enough. It wasn't covering all what I needed. And so basically, I had to create my own one.

OK. We have created a connector. So now, it's about creating a flow. The flow is basically where the steps, the action really happen. And we have three types of flow. One is the webhook. It's the trigger. So basically, something happens somewhere, and I get notified. And then on that notification, the flow can start and run and do the job.

The second one is the manual one. So I literally have to push a button within Power Automate, or maybe someone else. But it's me saying, execute it now. The third one is time trigger, every five minutes, every night every weekend, whenever you want.

So let's go and build a flow. So we're going to the flows. And in this case, we create a manually triggered. It's just simpler for this case. We don't have to set up webhooks, and so on and so forth. So we go and create now this manual flow. And we pick our custom connector, which has now one action, the Githubs.

It doesn't require any parameters. So we're done. We're good to go. Let's give it a try and say test. And there you go. We should be done. There you go. So here it's finished.

And if we click, we see exactly what happened, and we see the output. So we see here the list of hubs. And one of these hops if you spot it, it's called coolOrange. So I would like to know which projects are inside that hub, coolOrange.

Well, my connector is not providing me a get project function or action, so let's create it. So we go here and say get projects. There you go. And again, we have to provide an endpoint. So let's go back to the documentation page, pick the project, get the get products, copy the piece of the URL that we are interested into, and paste it here and say, it's a get.

But the hub ID is a parameter, so we put it in curly brackets. This is something that someone has to enter, right? And that's basically the idea of the given hubs. In my case, it's the coolOrange one, right? But it's a parameter now, so that's great. Update the connector. Let's go back to our flow.

There you go. And let's add an additional step. So we go again on the custom, the test, and we see here now the get projects. And the get project requires a hub ID. Well, we get IDs out of the get hubs, but we get a lot. I just want the one that applies to coolOrange.

So let's add an action here called filter, which allows me to filter the result of the previous step to get hubs, right? And in this case, we go and say, OK, please filter out the one where the name of the given hub is called coolOrange, right? Now, by doing so, I can now pass over the filter data to the next step. And in this case, then pick for instance, the ID of the filtered hub, called coolOrange, and we're good to go.

So how do I know this stuff? Well, I know how the outcome of the githubs look like, so the payload, the response of the action. And so I had basically think about how can I filter that data to take out what I need. Let's see if it's working and run through it.

And if we click now on it see now that get a list of projects, like the sales material, and then further down we should have also the technical material. And we actually, if we go on my team site, I see the sales and technical material on the order. So it looks like it did work correctly. All right, so this was now a simple flow. Let's go quickly back to our original example here and see how this flow really looks like, right? We saw it before quite quickly. Let's go a little bit more into details.

So the first thing is that when we save a milestone, then we have this trigger, new milestone, that we have been able to subscribe to. How to do it, it's documented. But again, it's basically instead of an action, it's a trigger, right? But it's the same story. It's a trigger. It has a URL. You point to it and so on, and then you basically have this event trigger.

So this event trigger then triggers the first action, which is gathering the component structure from my 3D model. Then we have a little bit of data manipulation, the same way as before where I had to actually filter out the data and grab the ID from the coolOrange hub and so and so forth. The same way here, we get this list of components, but effectively, the first thing I need is what is the parent? What is the top assembly component? And this is what I do in the first data manipulation, so that then with the next step I can actually add the parent item to Fusion 360 Manage, right? So that's the first step.

Now, at the very bottom, the last action here, the last step is adding the BOM. Now, for adding the BOM, I need to provide the Fusion 360 Manage the IDs of the items that I just created. And they are called TMS IDs. So it's not working to the number. It's working to this internal ID that Fusion 360 generates when you create an item.

And this function here, add parent item, it actually provides me back again some data. And in this data, I also have the TMS ID. So I have to store it. I have to remember it. So this is where the data, the next step of data manipulation happens. So take out the data and store remember basically, this TMS ID.

Now, the next step is then to look through the components. And this is what we have this apply each to child components. So we look through the components and we add again, of course, an item. And again, by creating the item, the Fusion 360 Manage will reply to me and say, yes, I can create it successfully, and here is the DDMS ID. So again, I have to manipulate the response and pick out DDMS ID, because he's telling me a lot, not only DDMS ID. So I have to manage and massage the data, and then we basically append it to our array so that at the last point, we can actually cycle through this array and then say, OK, please create this bill of material made out of this DMF IDs, right?

So it's not complicated. There is just this additional level of complexity where the data that is provided back by each call does not perfectly fit to the next step, right? So I always have basically to get something, and then massage it, and cut it down, and take out some information so that I can move on to the next step. Now, Power Automate provides me a ton of features and functions like this past JSON or initialize variable, or filter as we have seen before. There's a bunch of stuff that helps you exactly doing this, but this is something I need to do.

OK, this was about data integration. Let's talk about data interaction. And in this scenario here, I'd like to show you something I hope, nice. I personally like it. So I basically built a very small simple application in Teams, in Microsoft Teams, that connects to in this case, Fusion360 Manage, but could be anything else. Doesn't matter, right? And it gives me basically the ability to see, create, and change problem reports. In Fusion360 Manage, we have this workspace called problem reports.

And I wanted to have something very simple on the Team side just because maybe someone you know, sends me an email, or sends a message a chat, and I quickly want to create out of this chat a problem report, or maybe add some information, and so on and so forth. So Teams is my communication device. And I don't want to jump between the two applications. I just basically want to take a screenshot, whatever, and then or a picture, and then basically add it to my problem report right from within Teams.

OK, so let's see how this works. We have here again Fusion 360 Manage at the top left. We have then our Teams at the left bottom side, and then on the right hand side at the top we have SharePoint. And then I'll explain to you why we need SharePoint. But then at the bottom right corner, we have our flow from Power Automate.

OK. So let's roll the video. And we go into the problems, create a new problem. Before we save it, I will just start the Power Automate in test mode. Now, I don't have to do it. It will run anyhow. But just so that I can see what's going on, I basically set it in debug mode, in test mode if you want, right? But it's just for the sake of the video.

So I have everything set up. Before I save, I basically start here the test mode, the test run, and go back and now save it. And again, we have now a event, a webhook that triggers now this flow and say, hey, something happened on the Fusion360 side, and the flow now is running. And what we see now is that the data is inside SharePoint. So the same data has been created there.

Now, let's go now in our app and just refresh the UI, and there you go. We see it even here. And now, we can make a change. So we can go in Teams, and for instance, change the description and say, OK, do not check the photo, instead ask Marco for photo details, or whatever, right? Save it, and immediately, this change will be reflected in SharePoint, which triggers again, a different flow. You don't see it here, but there is a second flow that now pushes the data back to Fusion360 Manage and effectively, the data we see has changed in Fusion360 Manage.

Well, even too much, the priority type and source got lost. These are the little things that by playing with this API, I run into it. I explain you quickly why we lost the priority type and source. The API, specifically for Fusion360 Manage, when we make an update of the data, it requires that all the properties that are changeable are provided.

So in my case, because I'm actually just interested into title and description, my flow, I just took care about title and description, and I didn't took care about priority type, source, and so on and so forth. So what happened is that when pushed back to data, Fusion360 saw that product, add, and source were not there. And he guessed that I may want to blank it out. That was not my intention. It was just the result of not providing all the data.

Now, in order to solve that problem, I would have to go into my flow and make it a little bit smarter and say, OK, before I push the data to Fusion360, 360 Manage, I actually read the data from Fusion360 Manage all information, complete my object, right, with the changes that I made, and then sent back the whole package of data in one shot, right? So you see it's all doable. It just becomes a little bit more complicated because of the way that the API is built.

So let's see these two flows, the one is basically the left one is the one that pushes the data from Fusion360 Manage to two Teams. The right one is the one that pushes back. We're not going to details, but if you look at the right hand corner here-- sorry-- left side here at the bottom, we have here a couple of functions.

So as I mentioned, I tried to do all this without coding. In this specific case, I had to grab the data from Fusion360. And it was not formatted well, or easily formatted to use it here in this form, but basically, had to use a function like you do in Microsoft Excel. So you can basically create a function, right? In this case, the function is called outputs from test from this one here. I was just testing out a couple of things. And then take from the array the seventh element, and use them the title, right?

So it does work. But first of all, it's not really nice. And the second thing, how can I know that in future the title will be at the seventh position in my array? If this changes, then the flow is broken. So definitely here, we would need a better solution, a more robust solution.

On the other hand, if you look to the right sort of the way back, here we have the trigger from SharePoint. And SharePoint provides me here a very nice trigger that says, hey, if anything has changed, here it is. And he provides me the data in a very Power Automate way. So I basically get all the properties, all the columns I have in my SharePoint list, I get it as a property. And I can one-to-one just drag and drop them into my UI, and pass them back.

So you see that this row here has several steps, and actually would need even more step. This row here is pretty much OK. It takes the data, move it over, right? So depending on how the API provides you the data, you may have more or less work to do.

So let's build the Power App. Let's go into Power App, and we have here a couple of options. We start with data. In this case, we have here again a couple of options to start from blank or whatever. In this case, we choose the data from SharePoint. And the reason is that I can choose here between SharePoint, Excel, and SQL.

Now, SQL sort of goes back into coding, which I don't want. SharePoint, I could easily create a SharePoint list in my tenant. That's just a couple of clicks. And by connecting with SharePoint, I can here choose my back report list. The whole thing is set up.

Now, there is a way to connect with the API. We'll talk about this later. But that's not really fully working the way that I was expecting. And I will explain to you why.

So as of now, I basically have the SharePoint list where the data is going to push there. And so I can work with that against that SharePoint list. And the system now is building up the UI. So this is something I did not make myself. Power Automate did it automatically on his own.

He recognized the data set. He thought, OK, you may probably need a list on the left hand side with the search and the new button. And you may need a detailed area on the right. So the only thing I'm doing now is I'm just changing a little bit the user interface, and maybe change the title to be the number. I remove the number. I don't need it anymore, maybe also remove the DMS ID. I just need the title and the description, right?

And then maybe I made a lasting change where I'm saying, I don't want to have it in two columns. I just wanted to have as one column. So here on the form, I'm changing basically the columns from two to one. And now, it's basically in a vertical alignment. And that's it.

That's all. The funny thing is, that if you see the data you see here, this is already the data from our SharePoint, or actually, from our Fusion 360. So the thing is already working, right? I didn't wrote one line of code. And I have a piece of user interface which already runs. And I can try it out here right away.

I can even test it with different platforms. So I can basically choose to see it with an Apple iPad Mini, for instance. Or I can choose to go with an iPhone 10, or whatever, right, here in landscape mode, for instance. Or I can basically watch it within a regular browser or whatever, right? So you can see actually how your app looks in a different application. So this is great.