今日已更新 264 条资讯 | 累计 23847 条内容
关于我们

标签:#Power

找到 31 篇相关文章

AI 资讯

D365 Customer Insights for Our Own Sales Team (Customer Zero) (4) Error Handling

This continues from Part ③ . We have the system set to refresh data daily, but unexplained errors can sometimes occur. Symptoms The segments were not properly configured as expected. Checking System → Schedule showed that the automatic refresh schedule itself was fine. The data source refresh also appeared to have no issues. Opening the Unify screen, everything looks like it succeeded at first glance — but checking the Performance screen reveals that something is failing during unification. Drilling in further, the failure is happening at the Customer Profiles step. Resolution Steps Attempt to manually re-run just the "Customer Profiles" task → Error persists Redo everything manually from the data source refresh step onwards This resolved the issue successfully. Takeaway Since this is not a misconfiguration issue, patient repetition of the refresh process is enough to recover. Hopefully this saves someone some troubleshooting time.

2026-07-16 原文 →
AI 资讯

Customizing D365 Sales — For Our Own Sales Team (Customer Zero) (2) Common Settings

This continues from Part ① . In Part ②, we'll configure the common settings and the internal-processing Power Automate flows. Common Settings Setting Up Connections Open Power Automate ( https://make.powerautomate.com ) Go to "Data" → "Connections" → "New connection" and create a Microsoft Dataverse connection Do the same to create an Office 365 Outlook connection Basic Flow Creation Steps Click "Create" → select "Automated cloud flow" (event-triggered) or "Scheduled cloud flow" (recurring) Name flows in the format [Zone]-[Number] [Description] (e.g., "A-1 Opportunity Stage Stall Alert") Always run a test after creating a flow to verify it works 2. Internal-Processing PA Flows — 4 Flows (Write-back portions of A-4, C-5, C-6, D-3) Once the common settings are done, it's time to build. A-4: Write Back Stage Changed Date Without this flow, the stall-day calculations in A-1 and B-1 will not work. Implement this first. In Microsoft Dynamics 365 (D365), a "stage" refers to a major milestone in a process — such as a sales deal or customer engagement — that guides the responsible person through what needs to happen next. It's how a series of activities is visualized and managed. From here, all work is done in Power Automate. Step Task Details 1 Create the flow "Automated cloud flow" → select trigger "When a row is added, modified or deleted (Dataverse)" 2 Configure trigger Table: Opportunities / Change type: Modified 3 Add condition Add a "Condition" action: "When Status Reason (statuscode) has changed" 4 Write-back action "Update a row (Dataverse)" → set cr917_stage_changed_date to utcNow() C-5: Auto-Set Renewal Date + Auto-Create Renewal Opportunity (on Won) On Won close, two things happen: ① auto-set the renewal date to close date + 365 days, and ② auto-create a new Opportunity for the renewal cycle and add it to the pipeline. Step Task Details 1 Create the flow "Automated cloud flow" → trigger "When a row is added, modified or deleted (Dataverse)" 2 Configure trigger Ta

2026-07-01 原文 →
AI 资讯

Stop Guessing, Start Modeling: Relationships, Schemas & Joins in Power BI

A database without relationships is just a spreadsheet with delusions of grandeur. If you've ever stared at a Power BI report showing wrong numbers...totals that don't add up, filters that filter nothing, there's a good chance your data model was broken. Not a bug. Just two tables that should've been talking to each other… and weren't. This is your practical guide to data modeling, schemas, relationships, and joins in Power BI, what they are, how they connect, and how to stop getting burned by them. What Is Data Modeling and How Does It Work? Data modeling is the process of defining how your tables connect to each other inside Power BI's engine (called VertiPaq). Think of it like drawing a map between your tables, telling Power BI this column in Table A is the same thing as this column in Table B. When you load multiple tables into Power BI, it doesn't automatically know they're related. A Sales table and a Products table, sitting separately, can't filter each other. Data modeling builds the bridges. Power BI's model view lets you: Define relationships between tables Set cardinality and cross-filter direction Build star or snowflake schemas Create calculated columns and measures using DAX Under the hood, Power BI compresses and stores each column separately ( columnar storage ). Relationships are resolved in-memory at query time, which is why a well-structured model is blazing fast, and a messy one will bring your report to its knees. Key Concepts | Concept | What It Means | |--------------------------|-----------------------------------------------------| | Fact Table | Stores measurable events (sales, transactions, logs)| | Dimension Table | Stores descriptive context (products, customers) | | Primary Key (PK) | Unique identifier column in a dimension table | | Foreign Key (FK) | Column in a fact table referencing a PK in a dim | | Relationship | The defined link between a PK and FK across tables | | Cardinality | Describes how many rows on each side match | | Cro

2026-06-30 原文 →
AI 资讯

Connecting the Dots: Understanding Database Relationships and SQL Joins

Have you ever wondered how apps like university portals know which courses a student is enrolled in, or how they pull up an instructor's full schedule in seconds? The answer lies in database relationships - one of the most important concepts in backend development. In this article, we'll explore: What database relationships are and why they matter The three types of relationships: One-to-One, One-to-Many, and Many-to-Many How relationship schemas work (primary keys, foreign keys) How SQL Joins let you pull connected data from multiple tables To keep things grounded, we'll use one running example throughout: a University Management System . By the end, you won't just understand the theory, you'll see exactly how these concepts connect in a real-world scenario. What Are Database Relationships? A database relationship defines how data in one table connects to data in another. Instead of storing the same information repeatedly, relational databases organize data into separate tables and link them using keys . Think about our university system. We have a table for students and another for courses . A student can enroll in multiple courses, and each course can have many students. Rather than storing a student's full details on every course record, we store the student's info once and create a relationship between the two tables. This keeps data clean, reduces duplication, and makes updates easy. If a student's email changes? Update it in one place - done. Here's a simple visual of what that looks like: +------------------+ +------------------+ | Students | | Courses | +------------------+ +------------------+ | student_id (PK) | | course_id (PK) | | name | | title | | email | | credits | +------------------+ +------------------+ \ / \ / \ / Enrollments (links students ↔ courses) Now let's look at the three types of relationships you'll encounter. Types of Database Relationships 1. One-to-One (1:1) Each record in Table A matches exactly one record in Table B and vice versa

2026-06-29 原文 →
开发者

Connecting Sophos Central to a Copilot Studio Agent with Power Automate

I wanted a chat agent that could pull security alerts from Sophos Central on demand. Type "get Sophos alerts" into a Copilot Studio chat, get back a readable answer. No dashboard, no manual API calls. It works now, end to end. Agent calls a Power Automate flow, the flow talks to the Sophos API, and the response comes back formatted in chat. This post is how I got there, including the bugs that ate most of my time. The shape of the thing Three pieces: A Copilot Studio agent that the user talks to A Power Automate flow that does the actual API work The Sophos Central API on the other end The agent does not call Sophos directly. It calls the flow, the flow handles auth and the request, and the result gets passed back to the agent to format. Keeping the API logic in the flow means the agent stays simple. The flow The flow is named Sophos - Get Alerts , living in a solution called Sophos Integration . Here is the structure: [Trigger: When Copilot Studio calls a flow] | [Init ClientId] - String (Sophos Client ID) [Init ClientSecret] - String (Sophos Client Secret) [Init TenantId] - String (your Sophos tenant ID) [Init ApiHost] - https://api-<region>.central.sophos.com | [HTTP Get Token] POST https://id.sophos.com/api/v2/oauth2/token Header: Content-Type: application/x-www-form-urlencoded Body: grant_type=client_credentials&client_id={ClientId}&client_secret={ClientSecret}&scope=token | [Parse Token] - extract access_token | [HTTP Get Alerts] GET {ApiHost}/common/v1/alerts Headers: Authorization: Bearer {access_token} X-Tenant-ID: {TenantId} Accept: application/json | [Return value(s) to PVA: AlertsResponse = body('HTTP_Get_Alerts')] Auth is OAuth client credentials. You request a token, then use it as a bearer token on the alerts call. The tenant ID goes in an X-Tenant-ID header, not the URL. Where the credentials live This is the part people will have opinions about, so let me be upfront. The Sophos client ID, secret, and tenant ID are stored as flow-scoped variables wit

2026-06-23 原文 →