Name: Access Rights
Uploaded: 2025-10-02T16:55:06.040Z
Duration: 47 min 28 s
Description: Access Rights

Transcript for "Access Rights": Hello, everyone. We'll just wait another minute until everyone's here, giving everyone's this chance to to jump meetings. Alright. I think we had, a few more people joining. I think we can we can start. So hello, and welcome everyone to this Pigment webinar about a subject that we've been asked so many time to do, access rights. Who knows? Maybe it's the start of a series, but at least it's it's the first time we do this. So we're we're very excited. So we're gonna speak about, best practices and troubleshooting tips. We'll get in the agenda in a minute. Before we start, just to have a few housekeeping items. You'll see on your screen that you have a q and a box where you can ask your questions. If you have any questions, we'll we'll try to an answer all of them at the end of this session. Just so you know, if you miss something or you wanna share this, the the recording of this session, is going to be sent, in about twenty four hours. Alright. So, yeah, before, getting on to understanding what is access rights, just maybe let's let's have a minute to to to say who's gonna speak today. So first, Aurélien, do you wanna have a a word in presenting yourself? Yeah. Hi, everyone. Super happy to to have you on exciting topic, access rights. So my name is Aurélien. I go as Aurel. I'm a success advisory manager at Pigment. I've been here, for for two years. Basically, I help, clients, like you who are live in our system, with, technical modeling and, and adoption in general. Great. Thank you. Lucas, do you do you wanna say a word? Yes. Absolutely. Hello, everyone. My name is Lucas. I'm a member of the product management team, and I'm here because my primary focus is on product security. So heavily involved in the world of access rights. Besides that, I I dabble in views, on tables and, a little bit of the new and upcoming AI features. Really happy to be here and looking forward to talking to you guys. Alright. Thank you. And I'll just say a word. So probably some some of you guys know me. I'm a customer success manager, and I'm responsible of, different accounts here in, in London. And, I'm, yep, very excited to be here. It's been, it's been a long time I wanted to do this. So what are we going to to go over today? First, I'll make a general introduction on access rights, speak about the different concepts that we have in, Pigment, then, letting speak about the, best practices, troubleshooting tips that he has for you. And, after the theory, the the practice, So he'll actually show you directly on Pigment what it looks like, ideally, and, Lucas then will go onto the road map. There's a lot to to be said on that side since, it's it's a heavy topic for, the product team. Alright. So, a general overview, on this topic. So access rights in software, in Pigment, can be seen as a little bit as the access right of a physical building, actually, like an office building. Everyone who's a member can access the lobby, but not necessarily everyone can access the accounting office or the the room where the servers are. And this is because there are access rights. So we want to make sure that the right people have the right level of visibility and control, nothing more, nothing less, and and make sure that I mean, the the data that we don't want to share is safe. So this is one one very important aspect. AccessRite is here to protect your, most sensitive data, maybe financials, maybe HR, and to make sure also that the people that need to see it, need to act on it also have this, this right. Secondly, and it's also very important, access right is useful for your business workflows, to make things efficient. So if you wanna assign something some someone sorry, a role, may be, for instance, an analyst or a manager, and these people have different roles, you can do that through through the management of access rights. You can also segregate duties. For instance, if someone wants to do, to to have an approval to do something, well, that person will be, asking the approver who's who has another role and duty, and that can be set up through access rights. And I just gave an example of a process like a business workflow where you're asking for, an approval, well, this has also to be done timely. So that's the the third point here. It's that you don't want to give access before, someone requested it. And there are other examples like this that, make AccessRite a a good tool to solidify the user experience. Of course, there's also the aspect of compliance and auditability, because AccessRite supports that a lot. It eases the path to reach the regulatory, requirements that you might have, for instance, for for example, with, SOX that maybe some of you know. And, lastly, there is also, the risk of human error, that exists, and the access rights will limit, as much as it counts. They can be just accidental damage, just things happen, like deleting some some some data or or, yeah, or mixing up things. And some evil spirits might also, try to to do things that shouldn't be shouldn't be done. So access rights is easier to prevent that. And, last but not least, if access right is done right and is set up in in a way that it all is organized and functioning, it's also a way to support the business continuity, meaning meaning that if there's an error and if there's a mistake, which which can happen, well, fixing it is gonna be just much more easier, and and and faster. And so what does it mean, within Pigment, and what kind of lexicon do we use to speak about access rights? So on on this diagram, you you have, different elements. The the there are two main elements. The the first one, which is account type, you you probably heard of this. This is going to be your primary owner. This is gonna be your standard member or workspace admin. We're not gonna speak about this too much, but, basically, the account type, family is where you want to change things on the workspace level, to to grant, accesses on on that level, so really high level. And then there is the the role, and the role is basically a combination of, different elements, including these three, so permissions, data access rights, and board access. And role acts as a container that assigns a specific set of permissions and access to certain members of the workspace. So which combinations exactly? So we have permissions. Permissions is gonna be around, the actions that your members can do on the workspace. So maybe I'm able or not to delete scenarios. I'm able to configure views or not, or configure calendars. So this is permission. So the functional capabilities. Then on the other side, you have the the board access. So this is getting touch to who can actually view, comment, and write on your boards. So, really, the the outcome, that you you wanna share to to your members. And this is, yeah, the board access. But today, we're gonna really focus on the one in the middle, data access rights. And this has to touch with all the data, so all the blocks that you're working with, onto pigment, the dimensions, and if you grant the reading or the writing rights to your, members or if you don't grant anything at all. So I'm gonna, pass it on to Aurélien who is gonna explain in in in more depth what we what we have to date in Equifax France. Thank you. Thank you so much, Hugo. Alright. So let's jump in in terms of, like, best practices and troubleshooting tips. Here, I'm going to assume that most of you have some exposure to what access right is in pigment. Like Hugo mentioned here today, because it's a wide topic, we're really talking about, read, write abilities, within, within Pigment, not necessarily anything around, like, port permissions or some application feature permissions. But if you have questions, feel free to go in the q and a box. We'll have some time at the end so we can, we can cover that. K. So I'll start with the basic and the most obvious, but I I've seen it, like, so many times where we jump in, start building rules, start building rules, and we don't have a clear plan in mind. So please, please, please always start with a simple, identification of who are your key stakeholders, what are they gonna do, in the system, and within those groups of stakeholders, what sort of, like, data will they be able to access or not access. So I have this simple example of a matrix, down below. We could be we could build something that's much fancier and, complex, but, I think as, like, a a starting base, that would be good. And and the last point I'll make on this slide is, please make sure, on at least an annual basis as you continue your journey that you review your a set of access rights, because you're gonna build new applications. You're gonna bring more data. You're gonna create new metrics. Let's just make sure, we set some time aside every year to to review your plan and and ideally also document it. In terms of why we use read write rules, I won't spend too too much time here, but, I always think it was good to reemphasize why, why we do it. So the first one, the very obvious one is to prevent read access to sensitive data. Here, I'm thinking about roster data, salary data, bonus, but can also be on some other modules, where you don't want certain folks to access to some country's information or customer information. So just just make sure we we build those roles to accommodate for that. The second one around edit access, making sure we only give that ability to the folks that are supposed to make modification. As Hugo Schmitt mentioned, as as your at Pigment footprint grows and you have more and more users in the system, we wanna make sure they're not able to modify transaction list, dimension list, or data within metrics. We'll take a look at some, some examples of how we can set it up in Pigment, later during during the demo. And the the the other three I have, are also, like, very valid use case. Third one is around looking data with a workflow. So making sure we create a dimension where we have members like, not started, started, approved, submitted, and making sure, we anchor with submitted and approved. We anchor some, like, no no right rule just to make sure things are properly locked down. The last two, it's a best practice to lock versions to make sure other plans are locked and also to to the prior months of data. We we don't wanna change historical, integrity. It's not something that I see all the time with clients. So top three would really be like the the one we must have, in, your workspace. The other two, some strong consideration to be to be given. Okay. So moving on. This one, I think it's a simple visual that we tend to forget, but, ideally, two things. We wanna make sure we we're gonna layer in rules within your pigment application. I'll touch on that on the next slide. But one thing to to remember from that slide is we we always take the most restrictive, approach. So, in, this example, we have configuration one with, was giving that read write access to users. Second one's giving read no write. And in the end, when, when we look at a metric or any, block within Pigment, it's it's gonna be the no write, that wins. So it's applicable in all use case I have here. I'm not gonna walk through all of them, but one additional thing to remember is, like, if we don't specify, a no write or we don't specify a no read, just have blank By default, again, we're gonna take the most, restrictive rule. That's not how it was in the past few years ago at Pigment. That's the new reality for everyone that we called it access right v two, and everyone is on that same, same engine where if you don't define, we take the the most restrictive by default. Okay. Important slide here. I only have a few more. Sorry. I know it's a lot of content, but I just wanna lay the foundation before we go to, to the Pigment workspace. Here, an important concept we like to push is to make sure you apply all the rules you're gonna build and you're gonna define in your plan in, in layers to make sure we go from, like, sort of, like, the the least restrictive to the most restrictive one. The first one is gonna be around the roles. So we can see, on the right, we on the right, sir, we have some of the standard roles that are being defined, within your your Figma workspace. When you create an app, we're gonna have those roles. We encourage you to to use them. One, little, distinction I'll make is we highly recommend for non admin or non modeler roles to, set them to a read, no write, access write type. And see as contributors, I've read, no write designer, read, no write. And, I'll touch on that during the demo, but the the intent here is to make sure those non power users, I'll call them, don't have the ability to to to modify your transaction list, to modify your dimensionals, to modify some data you may not have anticipated could be could be modified. Number two here, as we layer in rules, we're gonna have, some rules that are anchored specifically on some dimensions. On the bottom right, I have an example of a country access. Right? So in rows, I have my users. In columns, I have my countries, and I define, read, and write, rules. The the matrix I'm showing is just, like, a a Boolean type, metric. I just formatted it. So, we have, like, green, boxes, red boxes, and it's just, more visual. But second, layer is, make it we make make sure you do it at the dimension level. Could be country. Could be cost center. Could be department. Whatever your business is, it's gonna be the type of, dimension that we that we add to the mix. Third one is gonna be your your workflow submission rule. That's sort of like the third layer of security we wanna apply. What do we do, with the data depending on the different stage it's in? If it's, approved, let's make sure it's locked. And the last one, I I talked about it before, looking past months, looking versions, always an additional consideration to to take. I'll take ten more seconds to talk about that warning I have at the bottom. In Figma, you have the ability to create, like, a a massive rule in which we you could have country department, cost center user, and and create that gigantic matrix of read write. We we don't recommend that. Instead, it's better if you do, simple rules like the one I have on screen, country and users. And and you have one for cost center and users, and you you have them, like, running in parallel, and they are additive to each other like we saw on the prior screen. The benefit of that, there are gonna be two main benefits. The first one is performance, because it's gonna be easier, faster for Pigment to read individual rules. And the second one is also, continuity of the process going forward, just making sure, just making sure if you wanna turn down the country in the future, then it's gonna be super easy. You just, turn up the rule, and then and then you get you still have the the cost center in place. Okay. This one, I'll show a demo of a centralized security board. Always make sure in your data app, you have one place to control rules, access right rules, work permissions. Ideally, you add instructions not ideally. You add instructions to your board, and you make sure, if someone else come in becomes the admin, they know what to do. Super useful. And I'll finish on that slide. Might be the most important one because it's around troubleshooting, and I I think that's why a lot of you are here today. So just gonna share some tips that I'm gonna demo right after. Number one, use the impersonate feature. You need to have the define application security permission, for it. But in the board or in the metric, it's that little, like, member icon that you can click on, and you can see things with the eye of your business users. So super important. Lucas will do a demo of an even better feature after. But for now, I'll talk about the one that's live. Number two, checking a member's access right. I'll show you in the settings. You can actually visualize exactly who has access to what. Super powerful and unknown features, so I'll make sure we we spend some time here. We'll review. One thing you'll have to do, after in terms of, like, tip to make sure your workspace is bulletproof, please, please, please make sure you review, the blocks that are being shared in the library. Too many times, I see workforce planning application with metrics that contain, like, employee level information that are being shared. That's a big no no. Like, don't don't do that. Let's make sure unless there's a need for it, let's make sure any, dimension that's dimension by any metric that's dimension by employee or seat, is not, being shared from the workforce application for obvious reasons. And, also, two more things. Dependency diagram, useful when you have, data coming from other apps to quickly identify, maybe what you might be missing. And I'll touch on the the the access right at transaction this level, something also we tend to oversee. So I'll I'll show you a quick setup and, and how to set it up for you in your in your application. Okay. So that's a lot of me talking. I don't know if there were questions in the q and a. It seems to be addressed, but what I'll do now and feel free to interrupt me, Hugo or Lucas. But what I'll do now is, switch, switch to, my workspace. Okay. And, okay, I'll open this PSP webinar. Perfect. Alright. So as you land on your home page, as you'll leave, you have a link that brings you to your, security board you can quickly access, here. Let's make sure let's make sure we have, some, action button that brings you to the boards, of your other apps where you can set, roles. You can also set specific, dimension access. Right? Specifically for for for I'm thinking about, some instructions. So next users will be able to to know, what to do, when they when they have a new users that comes that comes in. And and then, typically, we've got the role. So here, potentially, I would be able to to change my test account to some other, to some other role, etcetera, etcetera. Where I wanna show you what I've done is more around the, data access. Right? So that's so pick up the day. So here I've got that cost center matrix. For example, I can maintain if I wanna give Francheska, for example, read access, I can do that right here. And same thing for country. So just just one interface, easy to, to maintain and to know what's happening in terms, in terms of access. Right? I can have, like, a similar setup for transaction list access. And, ideally, I put my board access here as well. So, for example, I know who will have access to to what right here. Okay. So another recommendation we make at Pigment is to have, a test board. And here, I just have a link to my, to my test board. It's it's great, especially for a couple of reasons. I wanna say for sort of, like, new users, they're gonna take more of, like, a modeling or admin role to understand sort of, like, the step by step of what's happening. And, also, to have, some metrics where you know you have specific rules applied to them, and you wanna be able to quickly test it. Okay. So I'll take that example, in Pigment. The way it works is typically we have a matrix like that one where, we wanna give, some access. This is just a visual interface that I've created with, like, a Boolean formatting. But in reality, the the one metric that's created behind is this one. So right now, Mathieu here has can read, no write to The US country. If I wanna give him write access, I can just click here, and we'll see quickly it turns to write. So this is the UX. That's the rule. And the behind the scene is if I go into the settings, I can see how is my rule being applied. So here, I was looking at country, for example, and that's sort of like the the last step of the process. We need to make sure this rule that we created, that metric that we created is actually being enforced. Typical setup we make at Pigment is all the metrics that are using country. We apply the read and write rules. I'll just show you this one time. So here we find again the rule we were on, and we were displaying on the board. And here on the right, I can decide I wanna apply it to all the metrics using the specific dimension. I could be specific and and select one, select two. But by default, I prefer that third option because as you keep evolving your app and create new metrics, we wanna make sure they they get put in that, in that, rule. K. So I'll leave here. I'll come back to my board very quickly. One thing I wanna show that's gonna be, beneficial for for everyone here today is what I talked about first, the impersonate feature. So before I do that, I just wanna filter on my test account, which is here. Oops. Okay. So see, as Aurélien test, I can see, I can read and write in The US and also oops. Let me make this bigger. And we can also read in German. Okay. So that's for country, US, Germany. Remember that. And here, we've got only access to sales and marketing with that account. Can read, can write. Okay. So what I'm gonna do next is, take a look at this metric and impersonate that test account. So right now, I'm not in the test account yet. I have access to friends, for example. But as I impersonate here, I'm able to see that a real test only has access to US, Germany for sales and marketing. So pretty cool. Like, you have that ability to see, what the users would see on the board. There's also a board permission being applied. So, if I didn't have access to that board, I would have a pop up message. I think it's a good feature, but what I like even more is what I was talking about on the slide, the settings option. So here to access it, you go in that little, like, wheel for settings. You go to access rights. And two things here. First, you can see what rules are being applied to my metric, cost center and country, because this this metric is dimensioned by cost center and country. And you can go one step further where you can actually give you a detailed access view by member. And here, if I don't filter on my account, but let's say I take two or three, I'll be able to see by country and by, cost center because those dimensions are where I have rules being applied, what users can see or not, and what and also same exercise I can do with the right access. And here, if I just go back to, my test account, you should be able to see that I'm only able to write in The US for that specific customer. So super useful one. Highly recommend you to, to use this one when you have users reaching out to you saying, hey. I cannot see any data. Can you help me with that? You just go to the settings, access right, brings you here, and quickly you can identify what's, what's happening. Alright. So a few more demos for today. One thing I wanted to show you is around, transaction list. Here, as you can see with my main account URL, I can see every single column. But, what I've done is I've set up some rules. So I'm gonna come back to that data access right interface, Come back here, and I just wanna add show you this little rule I've applied here. So I created a read only rule. It's not a read and write. It's a read rule where I have three properties where I'm applying some, rules. So let's go in it. Okay. So as I come here, just gonna look at all users, I can see that, for each user, I have rules to say read, no read. Here, we're not interested by the write because it's just a read rule, but it's always displayed. And I've selected three properties, price, revenue, volume, where I don't want users that have no read to be able to to see that. And I think if I go to my test account, test. You see no read. No. Right? So let's see let's see it in action. And I leave this role, come back, go to my security demo board, and here's the transaction list. Okay? So right now, I can see those three columns. Again, I'm gonna show you the, impersonate feature. Gonna take my test account, come here, and boom. The data disappears. So pretty quick trick. Make sure in each of your app, you have a setup, being done at this level. One more thing I wanted to show you. We talked about dependency diagram. I'll touch on it extremely quickly. But, as I mentioned, super useful in cases where, some of your users are reaching out and saying, I I can't I can't access the data. You can go to that dependency diagram. Here, you would come to that drop down and select access rate. So instead of seeing data flow, you start seeing, access right flow. I don't wanna talk about, inheritance of data because it's a concept that we used to have. And, today, we recommend applying rules like I've been showing up until today. Where I think this is extremely useful is when I actually look at, data coming from other application. Just gonna zoom out. Sorry. One more time. I don't wanna do it here. I wanna do it on my OPEX. Okay. So I'll do the same thing. So you can see dependency diagram here. I select access rights. I select my test account. Okay. So here you can see the dotted line here means it's coming from another application. The red means I have no access. Most likely, it's because my test user doesn't have access to that PSP webinar second app, and that that would prevent data from flowing into the the metric I need. So that's all I have for today. I hope that was useful. Don't hesitate if you have questions to ask them in the q and a. Always happy to to talk about some some some best practices and how we, how we recommend to things, in Pigment. Alright. So so with all of that, I'll pass it on to Lucas. Thanks, Rafael. Yeah. I'm gonna talk a little bit about the upcoming road map. I saw some questions in the q and a, and I was trying to respond, but I'll get to them after I, do this piece right here. So, first, I'll talk kind of broadly thematically what we're working on. As we talked about at the very beginning, my scope in part is is product security. And the the focus of this presentation today has been around access rights. But as Hugo mentioned, the the scope of the product security features in general has a larger breadth than just access rights including board permissions, roles, and so on and so forth. All of these things together have been designed in such a way over the years since since Pigment's inception to be as versatile and functional as possible. Meaning that we wanted to maximize or guarantee the likelihood or the certainty that we can build to spec, basically. So we wanted to be absolutely certain that our system was capable of covering the security needs of any nuanced enterprise customer use case. And so we succeeded in doing that, in my opinion, and I think the opinion of of our customers as well, and you'll hopefully feel the same. However, as a consequence of that, we have what is often, communicated to me through feedback, as a system that feels quite decentralized and complex. And so my first and most important priority right now is to sorry. If we could go back one slide, please. Is to without compromising on the functional aspects of our security system, introduce improvements that allow it to feel simple to end users, allow the onboarding onto the access right system, which we're talking about today and naturally feels quite technical, to feel a lot easier and and kind of make the the the the ramp up feel a little bit less, resistant. That's the first thing. And the second thing is part of that effort to simplify, we also want to centralize. So for those of you that are are pretty familiar with Pigments workspace architecture, a lot of the configuration elements for security are at the application level, and access rights is very inter intertwined with how the model works itself. And so as a result of that, we often give feedback that it's difficult to find exactly the information that you're looking for about the configuration. And so, therefore, this is why, our priority, first and foremost, is to simplify the experience and centralize it, give you a a single, reliable access point that can tell you all the answers to the questions you're most likely to have when you come into Pigment trying to configure or audit your security. That's the first piece of the the the the scope that we're focused on. And the second piece is AI readiness. Now all of the folks attending here today, I was looking through all of your all of your roles at all of your respective companies. I would be surprised if any of you hadn't already heard about the Pigment AI roadmap. We obviously have a a tremendous amount of exciting features upcoming. Namely or most relevant to this conversation today is the modeler agent. And so we made tremendous progress there. But as part of deploying a modeler agent in your workspace, you need to have even more robust security. The way I think about security, there's proactive and retroactive security measures. Proactive would be something like access rights where I proactively restrict access to data that I don't want people to see. Retroactive would be something like an audit log where I can audit the actions of different members in my workspace and see what they've done and verify that indeed that all of the behavior is compliant. When it comes to an AI, we're talking about the most sophisticated, most energized, most enthusiastic modeler you could possibly imagine. They don't sleep. They search for the answers that they're looking for, and they don't care how frustrating, the the process of not being able to find the answers that they're looking for is. And so therefore, we are guaranteeing, that we can properly secure this model or agent proactively. I'll talk a little bit more about that later about what that means specifically. Could we go to the next slide, please? So, I'll talk I'll mention a couple of these, highlight a couple of the upcoming features. Although I demoed the current impersonation feature, we have a new version of this feature coming out very shortly. I'd hoped it would be ready for today, but it's still, got some kinks in it. I'm gonna demo it ahead of time, but, you know, be charitable when you look at it. There's a couple of of weird behaviors that I'll call out while I do it. That's gonna be really exciting for being absolutely a 100% certain about what a user can see and do in Pigment. It's a common feedback that, you know, I wanna know absolutely what user x can do and see. And getting to the bottom of that question is about to become a whole lot easier with this new feature. Additionally, because license attribution is so intimately related to permissions allocations and Pigment, like which permission or which features a user can use is very intimately tied in with how we price the the usage of that user. We're also introducing much more comprehensive UI that highlights exactly what license a user user has and why they have that license. And so it becomes a lot easier to manage licenses, if you're a partner for your for your clients or if you're a client for yourself. I'll highlight two more and then I'll jump into a demo. I'm excited about the super admin mode. This to me is a is a cool feature. It's quite intuitive. You want admins to be able to read everything. And today, because of the way that that access rights works, it needs to be configured explicitly. And it needs to although it just shows you how you can configure rules and you define your your access rights metrics that map a a particular access right to a given user for a piece of data. And so you have to do that for for admins as well. And so we wanna shortcut that entire process, make it super resilient, future proof. So you never have to think about it again. Admins can a 100% see all of the data in the workspace. So that's the idea there. Otherwise, like we see here, we're improving the admin experience with a couple of these features, and we are continuing to improve the experience when configuring, access rights themselves with the number of quality of life improvements, a number of technical or performance focused features that will allow, modelers to configure access right perform and access rights on larger and larger models to be able to share the configurations more seamlessly between applications and so on. I see a question here on the screen. Can historical data or approval data once locked be unlocked? Yes. So I believe I had answer. It's me. I wanted to to push the answer, and I shared it on the screen. It's, sorry about that. No worries. No worries. Yeah. But the there's a very similar question in the in the q and a on the side, and and the answer would be the same. And then long term, like I mentioned, we are focused we we believe we understand the the the root causes of the feelings of decentralization and Pigment, and and a lot of it comes from the way that the workspace and the applications are architected. And similarly, this is how we control the modeler experience as well. And so we're working on revising or or iterating on our entire workspace architecture as a as a means of, one, improving our modeler access system for a modeler agent, and two, improving the the the centralization problem which I had referred to on the previous slide. Alright. Next slide, please. Okay. So now I'm gonna jump into a very brief demo since we don't have much time left about, the full impersonation feature. Share my screen here. So I'm here in the same application that Aurélien has showed before. We can go to my home page and see all these different things. You should imagine yourself being in the shoes of an admin and the question that you're asking yourself is, I just configured this whole model. I wanna know exactly what this user sees when they come in. So the previous version of impersonation only showed you the access. Right? So I what what shows up here, on the on the left hand side, the actual features that they're able to use. I didn't actually know that, so I don't know what their comprehensive experience looks like. I only know roughly the data that they have access to. So this feature is really intended to give you a complete understanding of exactly what a user can see so that you can validate that the process that you've configured with the model that you've built is exactly to spec. And so the access point is right here. I can come here in my, roles administration page. I can click and I'm gonna impersonate this example business user who in this case we're gonna pretend is a sales manager. I'll go ahead and impersonate. This is part of the finicky stuff that we're gonna remove before we go live next week. Next week, you'll just navigate straight to the home page of the application that you started from. But now we're in an impersonation session. So I'm at the workspace level, which also previously wasn't possible. I can see all the applications that they have access to. I can see everything that they can do. I can even see what actions are available to them. Right? So that's pretty cool. I'm gonna click into this application, and you'll recall previously when it was my own session, there were a large number of boards and I also saw the blocks here. Now when I'm impersonating this user, I see only what they have access to, which is a small subset of boards. I'm also redirected to a different home page, which is the home page of the example business user that we're on. And I also see down here that they have a completely different subset of, features that are available to them. We didn't forget about access rights, of course. So now I I just previously showed you all the permissions that are available, but now we can also see that they only have access to a subset of countries. This user only has access to France and only has access to the sales cost center. So and that's reflecting the data that they see here. I cannot filter for any other countries. I can navigate through the, the whole flow, and I can see again access rights is is correctly reflected, which is convenient. And then finally, I'll show you what we see when we go to our, cost center, page. We can see that only page available for me to to look at is sales and marketing, and that's due to the access rights of this particular user. And if I am, for example, curious if they're able to make the inputs that I want them to be able to do, I can now click on a cell and I can test it. This is a read only session, so we're not actually making inputs, But we are getting feedback that this user does have right access on this cell. And that's super useful too because previously, when you made an input while impersonating another user, you actually made an input. And so this is really, really giving you full end to end understanding of exactly what this user can see and do in Figma. Finally, last quick details that I can swap between users without leaving the impersonation session pretty easily. So it makes for a nice kind of, like, audit experience. I'm at the end of my implementation. I wanna have, you know, a complete test run through and make sure that every user sees what they're supposed to see. Alright. I'll go ahead and stop sharing. Jump back here. Alright. That's basically it. Thank you very much, Lucas, and Aurélien as well for for your presentations. So we we had a few questions in the q and a as they as have they been all answered? Is it possible to assign account type and groups during the SCIM provisioning process versus manually through the workspace? I can speak to that one. Actually, I think we have to click approve so that they show up for everybody. Yeah. So the question is is via SCIM, which is the API that you can use to provision users programmatically from your identity provider to Pigment, the question is can we configure groups, the user groups, via SCIM? Right now, the answer is no. However, it's certainly on the inevitable road map. It's not prioritized for the upcoming quarter, but I'd be very keen to understand, your needs if that's something that's important to you. So I'd love to chat. Another question from Tabish. Is there a way to other users' action that they perform on the platform or on a particular app or board or table? Yes. Yes. Very much Definitely, you can do so with one of two features. Number one is the audit logs, which is an API that you can query and you can see a comprehensive history of events of all users in your platform. This is very, very important for public companies and those trying to achieve SOX compliance like you had mentioned. Alternatively, there's a there's a feature on the platform called history. It's associated with the view history permission in each application. And this allows you to see the individual changes and the values from the previous state and the new state for every piece of data in the in in the application. Cool. And last question, can we also track the user's activity when using the impersonate feature? That's a good question. I need to I need to I need to get back to you on that one. I would assume the answer is yes. And if it's not presently, it will be the way that case before we release the the feature. Oh, I'm sorry. You were talking about the the, existing one. Yes. Yes. You can see you can see the the behavior for the existing impersonation patient. I just need to verify for the new one that we're tracking that. Cool. If no other questions, we we can end it here. The other questions that were asked before were answered by writing. So well, thank you very much. Big thanks to Anne and Lucas for participating in in into this, webinar. And, of course, thank you guys for coming in. We will so we will send you the recordings, tomorrow. There will be also a survey to to see if there's something that we didn't speak about that you'd like us to to speak about next time because there should be a next time. It should be planned, soon for, focusing on other areas of access rights, so stay tuned for this. And, that's it. Aurélien, Ricardo, did you wanna say anything else? I'll I'll say one last thing. I forgot to mention this. I'm super keen to get feedback always. And I wanna emphasize, it's really great to hear, if you love what we're doing, but it's way better to hear what you don't love, because that's how we become better and we find problems that are worth solving. So I'm gonna drop my email in the chat. Please do feel free to reach out if if there's a a product limitation that you've encountered that that you want to get somebody from product's eyes on. Doesn't have to be specifically product security, although that's the space that I'm most likely to be able to help you. Thanks. Okay. Cool. Thank you, everyone. Thanks for your time. The next book. Thank you very much. Thank you. Thank you. Bye bye.