SANTHOSHBABU K

Hello. I'm Santosh Babu. I have been working with Accenture Solutions Private Limited as a senior analyst for the last 10 years and to speak about me in a brief passion. So, I am working as an analyst, wherein there is a tool which helps them validate the claims. It is a tool we are working with the aerospace claim. They have a built-in analytic tool, which helps them validate the 25 number of checks out of n number of checks. And out of these 25 checks, I have personally developed 10 checks which help in validating the tool. In simple terms, they are raising a warranty claim. That claim has to be validated in such a way that whether the claim is duplicate or whether the customer is raising a valid claim, the parts are legitimate. All these things are checked in the tool. And what are the technical specifications? We have SQL Server, which helps in maintaining the data and SSIS, which helps us as an ETL tool to validate the data, wherein we have hypotheses built in the SSIS packages. And using SSIS, we call a batch file. The batch file will execute the SSIS packages, wherein the output will be extracted in Excel using SSAS. And in the meantime, the modifications will be happening there in the SSIS packages themselves. And the final data will be extracted in Excel. We can also validate the data in the SQL Server as well. This is one of my jobs. And other than that, I used to publish Power BI reports for the client as well as the internal leads, wherein we will publish agents' performance, process performance, SLA data, KPI data, monitoring, and tracking of SLA and KPI for daily and monthly basis. And the claims incoming and outgoing data in a pattern that I'll be taking care of. And entire reporting and the data management, I'm the only one taking care of. And for the last six years, I have been building Power BI dashboards with simple tax expressions as well as wherever Excel VBA macros require, I'm the first point of contact. I will use entertainment studies based on the steps and the requirements. I will pitch in, and I will download the Excel macro. And that's it. That's a simple introduction about me in Accenture. Previous to Accenture, I have three years of experience with Pro. There, I have been working as an MIS analyst, wherein I help track the agent's performance and the incentive calculation. I used to take care of uploading the incentives into the payroll page. That's it about my previous experience.

Implementing and testing application security layer models, specific to Power BI integrations. So, I think I am not experienced enough to answer these questions, but there are role level security features in Power BI that help in validating the user's attempt in accessing the Power BI. We also have Power BI reporting server, which has data integrations, and we can monitor data usage and user login over there. When it comes to the security layer models, I'm not experienced enough to answer this question. And thank you.

So when it comes to large datasets in Power BI, obviously, we can even include Azure, AWS, and large datasets using Power BI. But what happens is when we have large datasets in Power BI, the performance of the navigation and the performance of the visuals may decrease. And what I tend to use is, mostly, when we use large datasets, I think we can use SQL in such a way that we can query only the necessary data and use only that data into the visuals. I think that's the prominent answer from my side. And also, I think accuracy is also important, obviously. Even in any other application, though, we have databases that handle GB levels of data, terabyte levels of data. Power BI is one of the front-end tools that we can see the accurate information from the entire database, and I don't believe the accuracy is compromised here. But when it comes to large datasets, the performance may get compromised all because of the application's ability as well as the system's ability. I think that's the problem.

When faced with a slow-running complex tax expression, how do you determine if it should be optimized or rewritten? Let's say if we're using different data tables or different tables altogether. Data tables in the sense that I'm trying to tell is fetching data from any other external data other than the table data. If, like, if we're fetching data from different tables, obviously, it may slow down. Also, it will be that if we're handling a large number of datasets, Power BI will respond very slowly. So, to optimize, I can say that we can bring all the tax expressions into one pivot table, wherein this table data can be called out when there is a requirement to the other table. I think this answers the question, which means, let's say I have a calculated field or I have a new measure introduced. I have a new column introduced using a text or any other built-in function using Power BI. What I believe is, let's say if we're bringing a new field, new measure from the other table using other tables' completion or other tables' filter. What I believe is that I suggest bringing those necessary fields into the same table so that we can use them to fix the performance issues.

When would you choose to build a new table or view in the database for a Power BI report? My previous question answered this question as well. Let's say if we are looking for a specific set of data where it affects the performance of the Power BI visuals as well. I think it's better to create a view or a new table in the database so that we can have a Power BI report that performs very well.

To ensure the security of the dashboards being viewed by multiple user prongs, I would take the following steps: What steps would you take to ensure the security of the dashboards being viewed by multiple user prongs? To ensure the security of the dashboards being viewed by multiple user groups, we can utilize Power BI's inbuilt functions to maintain viewer views. Other than that, we can introduce row-level security within Power BI, which helps in securing the data viewed by users. Obviously, RLS or row-level security is one of the prominent features in Power BI, which helps in handling multiple users.

Calculate some of sales and note, filter all sales that might be impacted. So if we are introducing this as a value or a visual in the Power BI, what I believe is this is only for the particular filter, I could say. This is only for the year 2022. Instead of using this tax expression, I believe we can apply a filter or else. Obviously, we can apply a filter and introduce a filter in the Power BI in such a way that if you use this filter to determine the sales, we can use it to filter the sales.

Analyzing the import snippet from Power BI's query editor, what would be the issue with how the table joints are being utilized, and what would be your recommendations for improvement. So sequel to excel workbook sales data. From there, I am using a sales table tab. There I'm using sales customer. So instead of using, So instead of using, table join, I and to be very clear that I'm new to the same code, I'm, I have been using this Power BI to build the dashboard, but I never use this, query editor, so I've had to, change or transform anything. But, I can bring the visuals in place whenever required to be very specific, I believe, both are from the same table. I think there will not be any improvement needed.

How do you design a Power BI reporting solution that accurately reflects complex business logic impacts without compromising their performance. Quoting solution that accurately reflects complex business logic in tags without compromising the report performance. And one of my previous answers already answered this question as well. Obviously, I use a separate table altogether if required. Otherwise, I built tax expressions, which will not take any data from any other external table, such that it will help improve the report performance. When it comes to complex business logic, this is kind of a hypothesis. I'm not telling my answer as hypothetical. When I say hypothesis, when we bring any large datasets, we will build a hypothesis kind of logic. When I say hypothesis logic, let's say, like, if I have six years of data, ten years of data altogether, this will be a GB level of data. So if we are going to analyze all this data to bring one field or bring a common field for a particular line item or data, we will call it a hypothesis. So when this kind of scenario is used, I think it's better to write an SQL expression instead of writing, I can call the SQL script or sorry, an SQL script in the tags instead of writing a complex logic in the tags. That's the way I can improve the report performance.

When setting up and maintaining an OLAP cube and strategy that works well with Power BI, I approach it by considering historical data needs. Obviously, when working in a live environment, Power BI cannot have all the data in it. If I load the entire data into Power BI, it cannot have all the data loaded into the back-end location or application. Power BI cannot handle the entire historical data. I believe I can call on SQL logic and scripting languages to get the data wherever required. Otherwise, it will be stored in the databases themselves. Instead of loading the entire data, I can use SQL to handle all this kind of data and bring it into Power BI.

Can we can you outline the process of creating custom connectors in Power BI for new type of data source not natively supported. Can you calculate in the process of creating custom connectors in the Power BI for new type of data source not natively supported. Power BI has inbuilt, data sources, and I believe there are n number of data sources which can, have it, which is applicable in the Power BI. And, if it is not supported, let's say, and, it's hypothetically, I can say, if it is not supported, I believe, we can load, the data into the databases wherein we can call the databases directly, which is already linked over there. That, is 1 of my suggestion. And since I have not used any other news sources other than the Excel, that's that's my answer for this question.