Now in part three, possibly the most important part, or maybe the part you need to think about most. Like everything else, when you've got it, you say, 'by Jove, I've got it!' Maybe not in old English. But we just need to think and understand. Because we need to create our publication in Paligo matches Zendesk. So we're going to publish from Paligo into a Zendesk category that already exists. We don't create categories from Paligo. They exist already. Then inside that category, you're gonna have in regular Zendesk as three levels, category section article. So the first level in your Paligo publication will be a section. Now, that's actually a regular topic in Paligo. But it comes as a section. And for those of you, again who understand Zendesk, a section only takes a title. Doesn't take any content, any of anything else. So your topic really just should contain the title. Anything else will be ignored. Then the second level, underneath the section will be your articles. Again, regular topics that become articles in Zendesk. If you're using the enterprise level of Zendesk, which means multiple hierarchies, then you might have first level section, second level section, third level section, and maybe your fourth level will be an article. Paligo works as you go along. It automatically says the last level of the hierarchy will be an article. And everything before that will be a section. And you're gonna have a whole mix. Just Paligo and the last one, the last level is going to be an article. For the moment of recording to my current or my current knowledge anyway, you've got a limit of five levels of sections in Zendesk, but please double check that because that could also change. They also might have my information slightly out of date. I don't know. But now let's go and see. It's really important to understand that because when I'm looking at some customers and they say they're having problems, I suddenly see an article in the top level, what they meant means to be an article that that's not right. And if you don't set up right correctly, you might get results that you didn't expect. Even if you've got Pre Flight, you might not notice. So it's so important. The first level is a section. Second level can either, will always be an article in your regular Zendesk, or it could be section section, then article at the end. If you're in the enterprise multi sections Zendesk. Let's go and see in more detail. So we've explained to you the different types of Zendesk you might be using the regular guide, category section article, or the multi section enterprise. What's really, really important is your Paligo publication properly matches how it needs to look inside Zendesk. Otherwise, it'll cause problems, errors, or unexpected results. And that's we're gonna go through right now. So if I click on this publication, I know when I'm looking at this, this is no good for Zendesk, and hopefully I'll be able to explain to you and understand why it's no good. As you may be aware, and we've discussed previously, the best way is to connect a Paligo publication with a Zendesk category. We don't create categories inside Zendesk. The category must exist first before we publish from Paligo. So we're mapping a publication with a category. So inside this publication, what we're gonna have is our sections and our articles. I'm gonna start explaining the regular Zendesk first of category, section, article. So if we look at this, the first one opening app will actually be my section, and these two underneath are going to be my articles. So this makes sense why fun stuff at the bottom is now no good. It would only be a section without articles and that's not how we do things, we need to have a section and an article. So we need to organize this. Another point to point out is that the section which is opening up in this case, in Zendesk, it's always only a title. So if opening app has lots of content inside it, it would all get ignored. Let's have a look what's happening here. So let's go to edit and open an editor for this piece of content. So all of the content in here would be ignored. That's not what you want. Right? What you need to do is you need to have topics that are specific for sections where really all you put in there is a title. Anything else would be ignored. So I created one called Zendesk section one. And there you see it has a title, but nothing else underneath. And what I will do with this one, go into my publication, and I'm gonna drag it into here, and I'll move it to the top. And I'll put opening the app inside of it. There we go. And so now we have that for a section. And this is an article. Now if we were in multi Zendesk, so this would also be a section and these would be articles inside that section. So Enterprise will show me two sections, Zendesk section one and opening app, and getting started, and create your first publication would be my articles. If this is regular Zendesk of just one category section article, what Paligo will do is actually say, I can't go further than opening app. This will be my article. So getting started and create your first publication will actually be sections inside opening app those of you know Paligo well, and you ignore this comment if you don't, it's essentially doing automatic chunking. It's saying opening app is the lowest level I can go. So the two sub topics will become subsections inside opening app. Hope that's clear. Maybe listen again, but I'll try to summarize it again quickly for you. If we're in enterprise, where my mouse is Zadia section one becomes a first section, opening up becomes a second section, getting starting for your first publications become the articles in there. If I am using only regular Zendesk, then I have a limit with any one section or more, and then multiple articles. So this is the lowest level I can go opening up and these two would become subsections inside opening up. So let's move them over now manually, just to work as a regular, the regular Zendesk, move that over as well. And now I have this one section with three articles in there. That's fine. And let's move Zendesk section two now over to here as well. Put that in here. Let's move adding users to the right. And in the same way, let's bring this one. However, we've got duplication, so we can actually take this one, and I'll remove it. And that now looks fine. And fun stuff is also no good, so I'll take Zendesk section three. I'll move that up a little bit. Move fun stuff. To the right. And now we have a totally normal and working structure and publication that fits to push into Zendesk, and I'll save. If you notice something that I've done, I've created this Sendex section. If you see here, it's actually just called section one. But over here, in the file name, The topic name, I actually gave it as a z-d at the beginning just by going to the three dots and rename, because I just recommend it's a good idea to have prefixes to your content, sometimes you have for other reasons. You have introduction multiple times. So at least in the file name, so you can when you search for them, you don't get too many results that basically a false positive, too much of the same result use use some sort of naming convention. I just called it z-d for now. So I know when I'm looking at it, it's a section. When I'm looking at the publication, it's also clear to me as well. Let me just give you one more piece of information if you're working on enterprise with a multiple sections. It's possible to have something like this. Let me just move getting started to the right. Okay. Now hopefully, this is clear. Opening app would be an article. Create your first publication would be a section. And this would be an article inside the second section. What I'm trying to show you is Zendesk allows you to have at the same level both articles and sections. So I was to push this to enterprise, opening up would be an article. Create publication will be a second section under Zendesk section one, and getting started would be an article inside, create your first publication. That's just us representing at Paligo what Zendesk allows you to do. But I don't wanna do that because the Zendesk we're using isn't enterprise, but you can test this yourselves later on your own enterprise. And like always, please make sure using a sandbox or a trial of Zendesk, don't push any content from Paligo into your active Zendesk until you're a hundred percent sure, and you can hundred percent predict what the result is gonna be. Because if you don't do that correctly, then you're potentially going to cause a mess for yourself. This is not hard. But I know from experience with myself and watching others, you need to play with it and get familiarities like anything else before you touch your live version. Now for something that maybe doesn't sound too appetizing. I say that because we're gonna talk about forks. But it's really important because you need to understand when does Paligo know when to create new content? And when to update existing content. It's all to do with the specific ID of the Paligo content, how it matches in our database with the articles. Let's go and see. I now need to explain something to you. You get a little bit maybe more into the detail. A little bit more of the technical side of Paligo, but don't worry it's not hard, and it won't take us long. But it's important to understand the ramifications of how does Paligo know what needs to be a new piece of content in Zendesk and when we know it needs to be updated? Now if you recall back, maybe you saw the the Paligo Academy video on authoring or you've learned it from the help or any other way. We have two types of, let's say, topics or components. We have origins and we have forks. I'm gonna explain to you again. So if we, for example, look at opening app on the left hand side, so opening app is the origin. I'm using opening app, you see in the publication here over there or the same way I can click here. I'm using it in this publication. I'm using it in a publication. It's called a fork. So the origin is the origin topic. And I'm using here in a publication called a fork. So if I use this topic in two publications, there'll be one origin topic and two forks. Three publication, three forks. Point number one. Point number two, each of them has their own ID. So if we look at opening app and I go to edit open structure, you will see that it has an ID of four eight four two eight. That's the origin ID. So if I click on the publication, let's go into here, and I click on opening app, You'll see it's got a different ID for it for two nine. Every fork ID has its own unique ID. It'll be different to the origin ID. So hopefully point number two is now understood. So in the Paligo database, when we push our content to Zendesk, Paligo matches the fork ID of the topic in here. Together with whatever the section or article ID is inside Zendesk. So the whole time this fork ID exists, after I've pushed it the first time, Paligo remembers to update in Zendesk. If this fork ID were to change, then Paligo would think, oh, this is a new piece of content. It must be something new in Zendesk. Right. You could use PreFlight as we'll see soon to remap it and reconnect them, but automatically Paligo wouldn't know. So when could this happen? And I'm telling you for examples I have seen, So say, for example, someone did this. They took opening app and decided I don't want it anymore. And they saved the publication. Then they come in again, and they bring opening up into it again and put it in the right place. You can understand. Paligo will think that's a completely new fork so it gets a completely new fork ID. So when it publishes it over to Zendesk, Paligo will not recognize that it's updates really should be an existing article. It will think it's new because of that fork ID. And I've seen places where people get confused by this and they think 'where's all the new content coming from'? Because it really should be, you know, it's an update. It's because the fork ID has changed. So hopefully you guys have understood really clearly that every topic when it's reused becomes a fork. That fork ID is unique it's different to the origin ID for that topic. Paligo's mapping or matching into Zendesk in our database, remembering that unique fork ID with the article or section in Zendesk. Really important thing to understand. So you don't go dragging things or moving things and creating a lot of these new IDs. I hope that's clear for you.