Name: Workspace Ownership and Maintenance in Pigment
Uploaded: 2026-01-29T17:01:06.223Z
Duration: 43 min 4 s
Description: Workspace Ownership and Maintenance in Pigment

Transcript for "Workspace Ownership and Maintenance in Pigment": Alright. I think I should stop sharing, and we are also gonna wait a couple minutes until everyone's here. Okay. Cool. Well, let's let's stop this. Thank you very much everyone for being here, and welcome to this new pigment webinar. This is a new, let's say, chapter in the series of the world of managing your your accesses and and and workspaces. And this one will really cover the space of how to own your workspace and maintain your workspace. But before, maybe some of you guys were there in October during the session about access rights and tips and tricks that we we explained on this chapter. We highly recommend for you to just jump on the community website in the events section and look for yourself what was said this in this session, because it was also quite instructful about the the world of workspaces. But today, we really speak about another subject, and we'll we'll dive in in this in a in a minute. Just a few housekeeping items in your interface. You might see chat. You might also see a q and a section. So feel free to ask any questions that you mind during the this webinar. We will try to answer them as it goes or at the end of this session. So what are we going to talk about today specifically? So after a brief introduction on on the topic, we'll dive into workspace ownership, what does account type mean, how to deal with your accesses in your workspace, and talking also about licenses. And then we'll move on to the main topic of maintenance and different principles around this. Alright. Who's going to talk? Oren, do you wanna say a word? Yay. Hi. Welcome, everyone. So Aurelia. I go by Aurelia. I work as a success advisory manager here at Pigment, which means, we help, clients, like you, when you go live, with anything, around, like like like technical, skills, coaching, or even adoption of the Pigment software within your company. So, yep, that's me in a nutshell. Thank you, Ariel. And there is also me. I'm gonna do the introduction of this webinar and and the first chapter. So I'm a customer success manager at Pigment. Maybe some of you know me. So I'm responsible of our different customers in EMEA mainly. And, yeah, I'm around in in Pigment for about two years now. And, yeah, I've actually heard I mean, heard a lot about the questions on workspaces and and and licenses, and so I thought, yeah, let's let's do a webinar about this. So without, like with no transition, let's go on to understanding why this subject matters. So when you're just out of an implementation of initial implementation of pigment or whether it's a new project that you just finished, we really saw that a clear, organized, scalable workspace is of great help to make that success long term. And it it goes with a clean workspace. This is this is quite core to what we're gonna say. I mean, it's just like a clean place to work. Users really appreciate when things are organized in a in a pigment workspace, mainly just doing some spring cleanings from time to time just to remove the things that are not in use, as well as inputting some color color coding of different items or even naming conventions, and we're gonna talk about this. Later on, when pigment is more established and there's there's, let's say, the the question of maintaining everything, and good maintenance is crucial. I mean, for security compliance, for instance, this this this is one item, but also for the more functional reasons. If your models are breaking or if you don't get results that make sense, you you need to be able to spot this quickly to to to act on it. And all along your subscription on of pigment, you also need to have an eye on your users and the the the accesses that you grant just to to also stay on track with your license licenses and be compliant with this. Also, if you don't wanna have a a call with your CSM, like a a surprise call to to speak about this. So role allocation is is is quite important, but also will give you some some red flags if some people will have a license they shouldn't have. And lastly, at any point within the the lifetime of of of pigment, it's it's good to to have good enablement. So I'm sorry. It's good to have good ownership and maintenance to grant good enablement because if there is something quite structured, it's it gives clear boundaries to your users so they they know what they can or cannot do, and as well as the navigation for them or through the workspace is made easier, and they probably will have less questions for your administrators or IT. So account types and licenses, because this is quite core to to this this workspace ownership, let's just come back to what we saw last time. This this is this slide is is only slide that was in this in the last webinar. I just took this one because last time we released, right, spending a lot of time on data access rights, which you can see right here. We also refer to permissions and board access. But today, it's really on top of this at the workspace level. What do we mean by role? What do we mean by account types? And how to govern this? Before we go into account types specifically, I wanted to just do a quick reminder on the user licenses, because sometimes we we forget about this, but it's it's quite crucial to to to keep that in mind. So explorers, contributors, and editor. Your explorer is your viewer. I'll go very quick on this, but can do any analysis they want. So it's act it's actually able to do a lot of things in terms of queuing and and, you know, also has access to Bigman AI documentation assistant. Also has access to Formula Playground to to try and test things out. If you want to input data, you're gonna have to go on the next license, which is contributor. Input data or import data. For anything else, so creating anything, being a modeler basically on pigment, you'll have to be an editor. So all the permissions of these different licenses are detailed here. I'm I'm just gonna skip this, but basically, you will you'll be able to see these more detailed slides on the documentation online. So account types now. So if you go on your workspace settings and and go on to your members management tab here, you'll see that account types appear here right next to the licenses. In this example, maybe not the best. You have no licenses in in these users because they were internal users, but you you you quickly see who is who. So the link with the licenses, because this is a a quite important aspect of your account types, If you're a standard member, you could be one of the three licenses. You could be an explorer, a contributor, or an editor. But as soon as you are one of the other type other account types above here, you have to have an editor license. So what do they do in in practice? So there is kind of a onion, Hugo, that you don't mind. I? just wanted to come back to. the to the prior slide because I I think that's an important one. Basically, in terms of the the account type when you're gonna set them, the the the the one thing to remember here is, like, anything other than standard member will trigger the editor license. So the the the one that gives you the the the most flexibility. But, typically, in a workspace, that's the one we only have three, five, 10 of those licenses. So, you really need to ask yourself the question, and I'm seeing that a lot as I work with customers. Do I really need to give that person anything more than standard member? With Builder, they'll be able to to build application And and all the other ones we have on top, Hugo will cover that, is a is a is a lot of, like, admin privileges. So, just just one thing is to keep in mind, basically, anything else than standard member will trigger the the editor license. Yeah. Yeah. Right. But it's true that a standard member can also be an editor, which would maybe not make that much sense because as you as you see here so one layer is actually one more type of write you can do, and and that's why we have different profiles. But a stem then a standard member will do whatever you grant them the license they and the permissions that they they they have. And and then you've got the builder. The builder is an editor that has the right to create or delete applications. And then above this so by the way, the builder maybe all your editors are builders, and that would make sense. But maybe in some cases, you will want them to be standard members to to avoid any unwanted deletions of applications, but that would be the only case, I I would assume. Workspace admin and security admin are different in the way that workspace admin is really about the functional things that you can do on your workspace. So viewing the plan and usage page, for instance, this we're gonna talk about this, but this is an important one. But also, I don't know, creating delete scenarios for other other people, managing connectors to your workspace is another functional aspect that you wanna deal while being an admin, when the security admin will have really them the power to see everything on your workspace. So even if they don't have access to an application, the security admin can grant themselves the access and and audit things for security reasons. And also one thing just to to add to that also, the the big difference, if you have a workspace and you have, two distinct use cases, let's say, on one end, like, typical FP and A type application, and on the other side, you're doing sales planning. If you need to have really segregation of data, workspace admin might be the better role. The reason for that is, as a security admin, you can add yourself to any application in the workspace. You can even visualize apps that, you're not added to, and you can add yourself as an admin. So so one thing to keep in mind before giving anyone security admin type, type, account type. Yeah. That's a good point. So security admins and then primary owners. I could have actually put another layer on this diagram for this role, primary owner, because it's kind of the account type, that rule them all. There is only one primary owner. It's a bit like if you had 10 security admins, you would have one primary owner that has the last word on everyone else. And this is quite an important role because it's usually given at the very beginning of your subscription. Sometimes people lose track of who has this role, but it's it's really the one that has the most power, period. And you can't edit this very I mean, lightly. So only the primary owner can give this role to an old another person, then we'll lose that role. Or if that person doesn't have access to pigment anymore, you you you can ask us and and contact us to to make the change, but we'll only be able to do this against your signature. So it's it's it's pretty important role. And I encourage you after this webinar to look who's your primary owner and make sure it's the right person. So, yeah, we we note here that it could be a a head of department or a head of the team, for instance. Okay. So here again, more info onto the different account types and the rights you permissions you have. Again, you can find this in the documentation online. And again, about the licenses and all the the things they can or cannot do depending on their license level. So last thing and a quick demo on on this topic, license management and make making sure you're kind of compliant with what your contract says. This is the page of plan and usage I was referring to. So if you're not a workspace admin, you you won't be able to see this, but it no. It is a sum up of your subscription. So what is your plan? What are the use cases included in your contract? And, of course, the licenses. So here, we give an example. It's a screenshot that gives an example of a upper usage. So you you have more people allocated as an editor than you you should be you should have. Sorry. By the way, the the the pigment users are not included, so they they shouldn't count as as someone using the license. So what happened if this is the case in your workspace? So I'm just gonna show you very quickly on on this mock up workspace where you can fix this. So when I go on my settings and then plan and usage, we can see here so my plan have a pigment plan, which doesn't exist anywhere else. It's just because it's an internal workspace. And I have my use cases and my usage here with with the licenses. So let's say that so I have a limit of five, ten, and 20 explorers. But let's say that I should actually have one editor maximum, and one contributor maximum, and one explorer maximum. Here I have three editors, so there is an issue. There there is some overallocation of licenses. So let's let's try to see how to fix this. So here, you see I have my three editors, Anna, Etienne, and Justin. Anna is the head of the team, so she is a security admin. It makes sense that she's an editor. So she's gonna stay the editor in this in this scenario. But Justin and Etienne, they should not. So let's see about Justin, what's what's behind this. So I see that he's an explorer on two apps that he has access to, but he's an editor on sales and revenue planning. So this should be quite easy to fix. So if I go to app security here, I'm now in the app roles and permission access page, and I can simply switch Justin from admin, which naturally makes him a an editor to reader because that I think that's what he should be. If I do this and just update this page Alright. Justin is an explorer now. So another case, Etienne, which who is a contributor on sales and revenue planning, that seems correct, as he's a manager, but he's also a manager on workforce planning, but his license type is editor. That doesn't really make sense. As a manager, in my terms, a manager is a role that should be a contributor in terms of licenses. So if I go there in the in the in the app, I can I can tell, yeah, he's he's a manager, but if I just go over this just information button, I can see that his permissions allow him to do creation of scenarios and deletion of scenario, which is not right? If you do these actions, if you allow a user to do this, they're automatically an editor because this is just something that an editor can do. So I'm just gonna quickly go on the roles, edit the role, change the application permissions, and just disable this. Okay. Alright. That's it. I'm just gonna come back on my members management page. Okay. And that's it. We have license editor, contributor, and explorer. And this should be reflected in our plan and usage. So one one one, which is what we wanted initially. Of course, this is just a demo. It's just to show you how you could kinda troubleshoot this. In in reality, it's a bit more complicated than this. We we know. But in in now is gonna show you how you can actually do this using some some some interesting features within pigment. So I'm. gonna go maybe the whole one. quick comment, I guess, from Go's demo, the key takeaway being it's it's not that hard to be compliant in terms of your license count. I know it feels a bit overwhelming, but as you go into the user, you get the apps they have access to and the different licenses that they trigger, you can easily go into each of the app and, and make the appropriate modifications. I know it would be great to have, better visual cues, in the product to tell which permission triggers what type of license, and we're working with the product team to to make it easier for for you to see that. But, but, hopefully, there was a quick demo that demystified, how how you can change the license type. Alright. So let me go ahead and share my screen. Tack. Tack. Tack. I wanna share here. Okay. And I'll go ahead on the second section. So, now we wanna talk about more around, like, the maintenance and some, some high level modeling principles. So one thing I wanted to to introduce to to all of you today is the the pigment modeling palette. I don't know if you've heard about that. For quite some time, it was only available internally, but now it's available to partners, to clients, and it's basically a set of modeling modeling principles, best practice guidelines, to help you, build in an efficient manner and a future proof future proof matter. So, I wanna show show you quickly what that is and where you can access that. When you go to our documentation, you can have access to a to a set of those modeling principles. Personally, when I joined pigment over two years ago, I decided to print everything, and I had that on my bedside table, and, and I was reviewing them. So not necessarily saying that you need to do that, but, personally, that was, that was really, really useful for The reason I introduced this is, specifically for, modeling for posterity here, the the third one I have on the top, because I think it's important for, for yourself, for your other users that we apply some of those modeling principles to be able to to be able to to maintain your your your apps and your and your workspace. Alright. So from that, I'm gonna walk through six different modeling principles and show you very short demos and and what they mean. So nothing rocket science here today, but just a set of of best practices. First one, I know I like to talk about access rights. I know it's not the funniest topic maybe for most of you, but, I think the having a secure setup, is is is extremely important, especially considering the the type of data we're loading into, into your applications. Specifically, I'm talking about, like, everything around, like, workforce planning, salaries, bonuses, things like that. We need to make sure the data is secure. One thing we know is, like, over time, like, the applications, the role, the the process, the access needs are gonna change. So what I really, really recommend, and that's from the the webinar we did in October, is the slide I have on the left, making sure to review your access rights, your security plan. My recommendation our recommendation is to actually document it. Could be in a in a table slide like this, could be in a Google Doc, could be in a Google Sheet. I don't care. But but make sure you have it, documented in terms of what are the different roles we need, what do they need to access, where, when, etcetera, etcetera. The second one to the right, in terms of troubleshooting your your access right, I think now in pigment, we have a lot of great tools to be able to do that. I'll just talk about the the first one. Those are two slides I I took from the the October presentation, but please, please, please, use the, impersonate feature. Now you can do a full impersonation where you can see, what apps, the user has access to, when you click in the app, what board, what metric, and exactly the data read write as they would see it. So so so please make sure to take some time during your build, after you build, any any any major change you make to to review that. So I think it's a good introduction to the next, principle around a secure setup is, using the the group feature. Why I say it's, it's kind of linked to your your access right, your read and write ability is because we we we don't use that feature a whole lot, that group feature, but it's basically one place in your workspace, settings, next to users, to be able to to create groups where we add users to them. And then we add, apps with, one specific role for each app, which is what I have in the in the diagram below. And it makes it super easy to, onboard, onboard people and and and to reduce access errors, in general. So might be a bit conceptual. So what I said we should do is take a look at an example. So I'm gonna go just to show you where I am. At the workspace level level, when you go into settings, next to member, you have this little tab called group. So here, you can create as many groups as you want. The the concept here being, when you create a group, there are two things you need to do. You need to add access to applications, and you can only add one role. So let's say I I take DataHub. Here, I'm gonna have the list of roles that are available within that application, and I can add it to the group. And then anyone that will be in that, group will have access to all those apps. Pretty easy conceptually. And then you have, the list of users. So right now, this group has three different users. K. One quick, quick thing. The reason why I think it's a it's a super important in terms of, like, maintenance, future proofing is, let's say, create a new username, John Doe, with his email address. Right here at the bottom, I can say right away, okay. This person is gonna be a contributor. I invite the member. I don't have to do anything else. The person's been added. They just need to activate their license. And after they have access to everything they need, no need to do anything else. One last thing I'll show in terms of groups, which I think is great is, as you'll see in this group admin, I have a member called, Frank that has access to the admin group. As part of the admin group, he has access as an admin to those two application. If I make a mistake and I try, to add him, as well to, let's say, the contributor, group, and I say, okay. I wanna be I wanna bring Frank. Tech, I take him. I add him, and I save. Automatically, there's a con conflicting access configuration. So I can review at the group level and, see that there's one role issue with Frank. When I click on it, it's telling me two important information. First, why there is a conflict because it's part of those two groups specifically for that application. And what Pigment does is it provides no access at all to to that app because we don't know which one to which one to trust. So that's just a a security security risk we're trying to to avoid. And if I delete this, remove the member. K. And now we're back, and we've lost that complete message. Cool. So, hopefully, hopefully, that makes sense. Moving on to the next slide. Creating admin boards, also something super important. When we build in Pignant, we tend to create a lot of metrics, a lot of tables, lots of views. But as, your team grows, maybe as your admin change, very, very important that you centralize all the administrative knowledge into one place. So different types of admin boards, we can have one to manage access right, one for data management when you have new new members, making sure you can add different tags and properties, FX rates, anything around, like, data imports, making sure you could have, like, tracking of the success of all your imports, data quality, making sure you don't have any member that are, missing properties or things like that, etcetera, etcetera. So don't wanna spend necessarily too much time here. I do have a few boards that I think could be valuable. Personally, I like to put them bucket them under, like, an admin type folder and and and give them, like, appropriate name. That way, I know what they're what they're used for. This would be my my security type, board where I can update I can update my permissions. We can have something around, workflow, which, I think, is a is a really, really effective way to manage where you're at, in your workflow. You can see how many tasks have been submitted, approved, not started, so you can can really keep track of your, let's say, budget, budget submission progress. K. Could spend a bit more time here, but just wanted to see you show you a few examples. Boom. Boom. Boom. Okay. Another important one. So not for all your users, but, maybe for your modelers or maybe just for your future self. I know when we when we build metrics, we tend to to build quickly, build the next metric, etcetera, etcetera, and we forget to to to make them, easy to read. So nothing groundbreaking here on my screen, but, I've got an example here where I've got, no line break, no comment on the on the first row. Can be really hard, harder, even though this one is not super complex for a regular user to understand what's happening. And and here at the bottom, we just we just enter line breaks, indentation, some comments, and makes it more digestible for whoever the the next person is to to be able to understand. What's cool is, now we've got an option that's called predify, predify formula. So I'm just gonna take a look at the one one of those examples. It's one of those new, AI features that were released, like, a month or two ago. And, of course, I'm doing a demo, so it's it's not loading. So in this example, I'm just doing a not such a great complex formula, but I'm just doing a a ratio. And I have this this formula right here. What you can do now, you can click on the three dots and that very first option called predefined formula, it's going to give you add some indentation and add some, some bricks so it's easier to read. And and as I was mentioning on the screen, then the only thing you have to do is just, add add your your comments like this. And that way, it's not a major lift. The the predefined formula worked, right away, and I'm just adding those comments. So just a quick and easy way to to to save yourself some time, your future self sometimes. One other fun one, consistent naming convention. One thing also I run into all the time when I work with clients and even myself when I build is it's hard to have the discipline, to to always, name things the proper way, and I I tend to change my naming convention. So what I have on screen here is just, what we find at Pigment the most logical way to do things. Of course, like, feel free to do whatever you want. It's just one best practice. But so using two two digits for anything around applications and folder will make sure it enforces the the log logical ordering in your in your folder structure. For blocks, use prefixes. First one being what's the business process, or what's the type of calculation you're doing. And then the second one is around technical usage. Is it an input? Is it a calc? Is it an override? Just just for for visibility transparency and and, again, future proofing your model for for other modellers. And then we've got, naming convention article, which is part of the of the the modeling principles. So so feel free to to check that out. Hopefully, hopefully, that saves you some, brain time time in terms of, like, okay. Well, how should I do this best? You just read that article, follow some of those best practices, and you and you can focus on the on the modeling. And the very last, modeling principle I wanted to to mention is, taking a snapshot at the end of your of your planning cycle. It's I know you spend a lot of time iterating, changing plan, v two, v three, version final, etcetera, etcetera. Whenever things are finalized and you can freeze them, just take some time to, to take a snapshot. What's great with snapshot is the data will, never move. It's completely frozen. You can also use, and call your snapshot as part of your your views, your tables, in your in your, in your metrics so you can compare your live data with your snapshot data and even make, like, calculations out of that. So so it's pretty pretty strong, pretty reliable. We make sure as part of, like, taking a snapshot type type cycle that you also delete, the old one because as soon as you reach your snapshot limit, you'll be blocked from creating new snapshots. And and the last thing I wanna mention that's that's not on the screen here is the fact that now, we've got a new feature where, the data that's contained in your snapshot, we can actually import it back into a a live model. That's something that was released a few months ago. The the amazing advantage of that is, a lot of time I hear from clients, oh, I wanna I wanna take a snapshot, but at the same time, I wanna be able to to modify my data because my CFO might come back with a change. And the the answer until now was like, hey. We took a snapshot. The biggest advantage is that it cannot move. So there's nothing we can do. But now we can bring back that data, work it out in a live model, and, and potentially take a take a new snapshot after that. So so one thing to keep in mind, and we we've got all the the documentation online on that front. Alright. That's all for me. I know it was a lot of me talking. Think we've got ten minutes left for for q and a. I I don't know, Hugo, if you something. you want to mention. Yeah. No. Thank you very much. Oh, I think you're still sharing your your screen there. Oh, yeah. Yep. Thank. Sorry. you. Thank you very much for for for this part. I think, yeah, we we haven't had any more questions. There's just the chat. Yeah. We we just have two questions about the recording, and and thank you for asking. Yes. You'll get the recording in in twenty four hours time. So so tomorrow. And and we should also pop in the the email with the recording, the slides, because there's so many links in these slides that could be useful, especially on your slides, Oreniel. So yeah. I mean, I a complete lot of questions going up, so so so we're gonna be able to use the ten minutes, I think. Alright. So if we go in order what did I miss? When is snapshots versus block restore usually used? So here, I'll set two different features. Snapshot here, the idea is really to be able to to freeze your data, and and capture an image like a screenshot of, your data at a certain point in time. Typical example is you finished your budget 2026. You've got your final revenue, net income number. You wanna make sure it's safe somewhere. When when we talk about, like, block restore, this one, it's more a feature for modelers to be able, let's say you you made a major mistake. You deleted the formula or you you changed the dimensionality or you just deleted the block, we give you the ability to to restore that metric, restore that dimension, restore that transaction list back into your workspace. So so so so it's so it's so it's safe. So so that's more like on the on the actual block and and elements. Hopefully, that answers it. Don't hesitate to to to to keep asking if you have clarifying questions. Next one is can I use AI to help me write metric syntax? Amazing question. We've got the the modeler agent coming up. It's gonna be in beta in a in a couple of weeks. I'm actually doing some testing right on the Mundler agent. I spent my afternoon and evening last night playing with it because it's I was able to start building an app, building metrics, building views, building boards. It's I think it's gonna be it's gonna be a a great one. So stay tuned on on that. And one other from Jean David. Hi. About about restoring snapshot, is it possible to do it on a part of the application? Example, for what entity? Yes. So so when you wanna import data back from a snapshot into your application, you you actually need to choose to which it's like doing a metric import to yeah. Metric to metric import. So you have in that interface a set of filters. So if you wanna filter at the entity level, you could say entity entity one, and only that data will be will be imported. Will the mother agent be at an additional cost? I don't know. That's yeah. I don't wanna say anything that I'm gonna be no. I I don't know. But we we can follow-up with with you on on that one. And we have a follow-up question from Todd in the chat. So makes so I should think of snapshot being used to restore data within blocks and using block restore to restore metadata. Exactly. Yeah. You you got it. That's exactly that. Yes. And last question, if it's the last on the Q and A. On the q and a, we've got one more. Sorry. Which one is it? Hugo, I think I missed it. I can't I can't read it out loud. Is there any best practice to set up security in one application, preferably in central data hub, when we have multiple apps in our workspace so that we do not have to set up security in each app separately for an admin. Yeah. Absolutely. So on that one, I recommend you watch the webinar we did in October, and it's going to be part of the email you receive in twenty four hour. Twenty four hours is gonna be included. Yes. Like, short answer is yes, as long as it's within the same, process, I wanna say. So if we took FP and A, you're gonna have your your data hub, revenue, workforce planning, OpEx, all of that. You can have Yeah. One central board in the data hub, and and that board can control all the all the metrics from all the the other applications. It's actually the the best practice we we recommend to do. Then if you start having two processes, like, the new planning on one side, rev ops, and on the other side, f p and a, and it's two different type of admin. In that case, I'd recommend you have two, two security, two security boards into different apps. Good. I mean, we're just three minutes from the end. I don't think there's a there are any other questions? No? But you'll see something pop up on your screen. This is just a survey to ask you what you you thought of this session, if if you you think you'd recommend other other sessions, any modifications you'd like. So as I said earlier, the recording will come in about twenty four hours. And I just have to thank you everyone for coming in to this to this second volume of access rights and workspace ownership theme. We know it's not the sexiest, but it's nonetheless very important to to know about these things, and and that makes for a long term success on using pigment. Thank you, and thank you very much, Aurinia, for for coming and you. and answering all these questions. Thank you, Hugo. Thank you, everyone. It was a fun one to do. Talk soon. you, guys. Bye. Bye.