This blog was written by both Megan Mueller Jensen and Randy Roosekrans, supporters and members of PRISM, Perficient’s Employee Resource Group for our LGBTQIA2S+ colleagues and allies.

As cisgender straight people in a professional setting, we believe it’s our responsibility to do our best to support our LGBTQIA2S+ colleagues. We are longtime allies, advocates, activists, and parents of gay kiddos, and we want to share a few things we’ve learned over the years about making our workplaces safer, friendlier, more inclusive, and more supportive for our queer colleagues. (For the rest of this writing, we’ll refer to these folx as ‘queer,’ which is an umbrella term although we recognize that not all of this applies to everyone.)

1. Pronouns matter. If someone tells you their pronouns, the bare minimum we can do is respect that and use those pronouns consistently. And if you slip up in conversation, correct yourself, apologize briefly, and move on. Doing so will signal that you’re making an effort; it becomes easier with practice. If you’re not sure of someone’s pronouns, it’s ok to ask! Simply say, “I use she/her. May I ask what you use?” It’s also great to include your pronouns in your email signature, when introducing yourself, joining a meeting, or on your LinkedIn profile. It’s a positive signal that lets queer folx know that you’re a safe colleague and partner to work with, and that they’re cool being themselves around you.
2. Respect and protect the privacy of your queer colleagues. Just because someone has disclosed information to you (or within PRISM events and conversations) doesn’t mean you have permission to share that with anyone outside of that original conversation. It’s ONLY the decision of queer people themselves to whom they want to come out. That information may not be safe or smart to share anywhere else. If for some reason it’s necessary to divulge details about others, make sure you get their permission first.
3. Educate Yourself. Take the initiative to educate yourself about queer issues, terminology, and experiences. There are plenty of resources available online, such as articles, books, and documentaries that can help you understand the challenges faced by the queer community. While most queer folx are happy to answer questions, it can also be emotionally and intellectually exhausting to constantly be the sole source of information, or if there is an assumption that they “represent” all queer folx.  A few great resources include HRC (Human Rights Campaign),  GLAAD (Gay and Lesbian Alliance Against Defamation), and The Trevor Project. PRISM also hosts informational events throughout the year that are designed to help us all be better allies.
4. Speak up, even (or especially) when queer colleagues aren’t present. If someone misgenders a colleague or uses offensive terminology, intentionally or unintentionally, it’s our responsibility to correct them in a friendly but consistent way. Stand up for folx who aren’t in the room. It sets the standard for expected behavior within the team and reinforces a supportive company culture. To that end, be very mindful of “deadnaming” which is using the name a trans person had before they changed it to what they use now. It can be deeply traumatic and triggering for them to hear that name in any setting. If you happen to make that mistake, you can offer a quick, sincere apology and keep the conversation moving.  If you hear a colleague using the deadname of someone who isn’t present, it’s a good opportunity for a friendly correction.
5. Support queer-inclusive policies. The needs and challenges of our queer colleagues may be different and more impactful than ones we experience as cisgender folx. Don’t make them fight for equality and inclusivity alone. Make sure they know you are in their corner and follow that sentiment with action.
6. Remember it’s not about YOU. As allies, it’s our job to support, facilitate, and enable the efforts of our queer colleagues. Big decisions should be made by queer folx, and our role is to help make their lives easier, safer, and more equitable. Try your best to give input, ideas, and opinions regarding queer life when invited to do so or ask if you can add your perspective when it might be useful.
7. Be open to listening and open to growth. Even with the best of intentions, we won’t always get it right. We may unintentionally say something dumb or stumble over our words. If a queer colleague corrects you or gives you input, see it as a sign of trust rather than criticism.

Understand that there are many facets to queer culture, and some norms may vary. The more exposure and practice you get in these spaces, the clearer those norms will become. The most important thing is that you approach these interactions with respect — everything else falls into place!

In closing, CONGRATULATIONS TO YOU! The fact that you are reading this article and showing an interest in this topic demonstrates your allyship, and your willingness to help make positive changes within the queer community. Thank you for being who you are! Let’s help our colleagues, clients, friends, and loved ones in the queer community feel welcome to be the best versions of themselves, too!

The post 7 Ways to Be a Better LGBTQ+ Ally at Work appeared first on Perficient Blogs.

Earning the AWS Golden Jacket is a remarkable accomplishment—one that reflects deep technical expertise, persistence, and a commitment to continuous learning across the AWS ecosystem.

What Is the AWS Golden Jacket?

The AWS Golden Jacket is a recognition given to individuals who hold all active AWS certifications at the same time, demonstrating expertise across the full breadth of AWS capabilities, including cloud architecture, DevOps, security, data, and machine learning.

Because it requires maintaining every certification concurrently, this distinction signals both depth and breadth of knowledge across AWS services and domains.

What This Achievement Represents

Earning the AWS Golden Jacket reflects more than completing a set of certifications. It represents sustained focus, discipline, and the ability to operate across a rapidly evolving cloud ecosystem.

To reach this level, Gonzalo built and maintained expertise across a wide range of AWS services and domains, while continuously adapting as the platform evolves.

This includes:

• Mastering AWS services across architecture, security, data, and AI/ML
• Maintaining all certifications simultaneously as they evolve and require renewal
• Applying knowledge to real-world scenarios where design decisions impact scalability, performance, and cost
• Staying current with new services, architectural patterns, and best practices
• Balancing ongoing learning with day-to-day client delivery

That level of commitment signals expertise that stays current as AWS continues to innovate.

For our clients, that translates into real value. It means working with experts who can connect capabilities across AWS services and design solutions with a clear understanding of how to align technology decisions to business outcomes.

Powering Our AWS Practice

Gonzalo’s achievement reflects the strength of Perficient’s AWS practice and the expertise we bring to clients as an AWS Premier Consulting Partner.

Our teams deliver solutions aligned to key AWS capability areas, including:

• Cloud architecture and modernization
• Data and analytics platforms
• Security and compliance
• Artificial intelligence and machine learning

This work is backed by:

• Deep, cross-functional cloud expertise
• A strong culture of certification and continuous learning
• Proven experience delivering complex, enterprise-scale AWS solutions
• A focus on driving measurable business outcomes

A Milestone Worth Celebrating

The AWS Golden Jacket is a significant achievement that reflects both individual dedication and the collective strength of our AWS practice.

Gonzalo, congratulations on this well-earned recognition. Your expertise, curiosity, and commitment to continuous learning make a meaningful impact on our clients and our team. We’re proud to celebrate this moment and look forward to what comes next!

Read more about Perficient’s AWS practice here.

The post Celebrating Gonzalo Munoz’s AWS Golden Jacket: A Milestone That Reflects Excellence appeared first on Perficient Blogs.

Headless Page-based Authoring Tutorial Preface

This tutorial assumes that you have a basic understanding of Universal Editor’s purpose and AEM’s architecture. It is also not intended to be a comprehensive solution design for the AEM-App integration nor a complete Universal Editor tutorial. Considerations like instrumentation details, caching, app security, and which authoring options are made available are beyond the scope of this tutorial.

Step 1: Enable AEM Page Content for Export

You can certainly use the pre-configured model JSONs of AEM Core Components. However, they have several fields that are not relevant to my downstream application, like gridClassNames and allowedComponents.

So instead, I prefer custom Sling Models. This gives us a granular level of control over which fields are exposed to our downstream application.

Start by creating a Sling Model for your Page component. Configure the @Model annotation to utilize SlingHttpServletRequest.class as an adaptable so it can serve web requests to a .model.json path and match the resourceType property to the resourceType of your Page component. Configure the @Exporter annotation to use the Jackson library and support a JSON extension for export.

You’ll notice that I’ve created a getItems method that returns a list of objects. This method utilizes a custom HeadlessUtils method that looks for (almost) all children resources of the Page and adapts them to their matching model based on their sling:resourceType. This is very important, as we want each child component to export its JSON based on its own model, not relying solely on the model of the parent.

I can re-use this pattern for other container components, components like Responsive Grids or Columns that have any number, names, and types of children.

Then I can similarly configure Sling Models for all components that will appear on my page. The primary difference in how I configure these other component models is that they also need to be adaptable from a Resource in order to be exported by the getItems method or other resource-based retrieval.

Once I have done that, I can load the export of any Page that uses this model as JSON.

Step 2: Consume the Page Content Downstream

For this example, let’s create a small connector library to AEM using JavaScript. Ultimately this could be run server-side or client-side and rendered however I like. The purpose here is to show that regardless of what downstream app I have, I can use a simple REST-based GET to retrieve the data.

You may notice within the code here that I’ve abstracted out the concept of a full AEM path from the rest of my application. This is because I don’t want to force the downstream application to adhere to a specific route structure. Perhaps in my app, locale is determined by the domain and not the application route.

Further, though I want to display published content on production, I still want to edit content in the AEM author environment before I review and publish it out. If I don’t have an “author” version of my downstream app, I need a different means to instruct the app to pull from the author environment. So I use 4 key parameters:

1. The matching AEM base path – This comes statically from my route. I do not allow open-ended user-editable paths for security reasons.
2. (MSM support) Do I want to view the language-master or the rolled out live-copy?
3. (MSM support) What locale am I in?
4. Am I currently authoring?

The latter 3 act as flags which modify the base path. These flags could come from URL parameters, session storage, cookies, etc. In my case, I use URL parameters because I do not want cached AEM content while authoring.

Now, in a real implementation, to access page content in an author environment, my code needs to authenticate to AEM. This can be done via a technical account (preferred) or temporary developer token. Select one of the options linked, follow the instructions, and then come back.

Publish environment content is typically public and therefore does not require an authentication token.

Step 3: Configure AEM to Open Pages in Universal Editor

Now that I have my Page Model rendering in my downstream application, I can configure AEM to open pages of a particular path and sling:resourceType in Universal Editor. This is done by adding an OSGI configuration for the Universal Editor URL Service, which you can also read more about in Adobe’s documentation.

The mappings field has two parts: the parent path for which the Universal Editor should be opened and the target downstream application domain. [parentPath:applicationDomain]

The resourcetypes field defines the sling:resourceTypes that should be opened in Universal Editor. In our case, this is our page component.

The aemDomain field signifies that the Universal Editor should be opened on the same domain as AEM. This is critical, as being on the same domain allows sharing our user’s Adobe IMS login token with Universal Editor. This login token is later used by the Universal Editor to write back our authoring changes to the JCR.

Now authors can click the Edit button in AEM Sites Admin and have the “page” open in the context of the downstream application with Universal Editor.

This one step helps close the loop for authors. We’ve moved Universal Editor authoring as a separate domain authoring tool to integration directly with AEM. It also allows authors to continue to think about downstream app routes as “pages” in AEM even though they aren’t being rendered by AEM.

As an aside, you might notice that I’ve specified a /preview route in the downstream application; why did I do that? AEM doesn’t know which downstream app route to open for a given page. All it can do in this integration is pass details like the AEM content path.

As I said earlier, I don’t want to force my downstream application to adhere to a specific route structure. I certainly could do that; I could update the mappings field to “/content/nextDayAEM:localhost:3000/${path}”.

This would make the page /content/nextDayAEM/language-masters/en_us open like localhost:3000/content/nextDayAEM/language-masters/en_us instead. But now my app has to handle any number of route combinations.

So instead I use a common /preview path and let the downstream application figure out what route maps to the aemPath parameter and do an internal redirect, passing those 4 key parameters I identified earlier. If I’ve configured everything correctly, the downstream route + parameters should match exactly 1 AEM page.

Step 4: Write Authored Content Back to AEM

Now move on to instrument the downstream application for Universal Editor. This step involves loading the Universal Editor script, adding data-aue-* attributes to your downstream app components, and adding JSON configuration files. All of that really requires its own tutorial. So I’m going to send you over to Adobe to explain that part, but note that this example uses content fragments. The only major difference in this instrumentation for page-based resources is in the Component Definition JSON, where you should specify the plugin property as “aem” :{ “page”: {..} } instead of “aem” :{ “cf”: {..} }.

Now that all of that is complete, I should be able to log in to AEM and edit a “page.” As far as the authors are concerned, all that’s changed is a new page editor experience. This has far more ramifications than you might expect at first glance. Let’s review the headless challenges we identified from last week.

1. How does an author track content downstream from the CMS? Content is now tracked 1:1 with a “page” that matches a downstream route.
2. Useful AEM Page tooling is not available out of the box for Content Fragments. We’re now able to use Page-based tooling like link browsing, asset page references, link rewrites on moves, page launches, MSM, etc.
3. Link checker no longer functions, as AEM does not have any inherent knowledge of the downstream routes. Though AEM can’t directly check the downstream routes, it can check AEM page-to-AEM-page links.  You can have authors link them as AEM paths via the page browser and use the same route mapper you developed in Step 3 to render the links.
4. Downstream applications pull in fragments by name or by query. Whereas Content Fragments had to have unique names, Pages, due to page hierarchy, can always match the route name.
5. Existing AEM authors are typically more experienced with creating and managing pages instead of content fragments. Fixed.
6. It creates a platform disconnect. Authors must navigate to AEM to create Content Fragments but navigate to the downstream application or the Universal Editor to view changes in context. Universal Editor now exists on the same domain as AEM. It looks like part of AEM, not a separate tool.

In other words, many of the challenges we faced with a headless AEM experience are no longer relevant when we use page-based resources as the source. We’re able to leverage the strengths of traditional AEM Page Tooling because, as far as AEM and JCR are concerned, this content exists as real pages in AEM, even though all rendering can take place outside of AEM.

I hope this makes you as excited as I am, as Headless experiences just got a whole lot easier to manage!

What’s Next?

Have a tutorial you’d like to see next?  For more information on how Perficient can implement your dream digital experiences, we’d love to hear from you. We’re certified by Adobe for our proven capabilities, and we hold an Adobe Experience Manager specialization (among others).

Contact Perficient to start your journey.

The post Implementing Headless Page-based Authoring in Adobe’s Universal Editor: Part 2 appeared first on Perficient Blogs.

Fewer Platforms. More Capability.  

The era of stitching together six different platforms to run a modern data environment is ending. Not because the tools got worse, but because the expectations got higher. Enterprises need data foundations that don’t just hold data. They need platforms that activate AI agents, automate management, and give information directly to the people who use it.  

These aren’t incremental feature releases; they’re a coordinated move toward a single platform that does more so you don’t have to manage more. Take native streaming, for example. Historically, if you needed real-time data pipelines, you needed separate Kafka infrastructure on top of your data warehouse. That’s overhead your team shouldn’t be carrying. Snowflake’s push toward native streaming capabilities means those separate pipelines, and the teams managing them, can consolidate into a unified stack. 

Adaptive compute extends that logic further. Instead of manually tuning and allocating compute resources across workloads, the platform adapts automatically. And the Trust Center brings AI guardrails, evaluations, and governance controls directly onto the platform, not bolted on from outside, not managed through a separate tool. Governance that lives where your data lives. 

The direction is clear: your core data platform should do more, which means you need fewer products to run your enterprise.  

CoCo for Builders. CoWork for Knowledge Workers.  

Two capabilities in particular signal where agentic AI inside the data platform is heading: CoCo and CoWork.  

CoCo is the agentic development tool, purpose-built for the people who build on the platform. It accelerates how engineers and data teams construct data products, applications, and pipelines within Snowflake’s ecosystem.  

CoWork is built for everyone else. It’s the AI agent layer for knowledge workers: the analysts, operations leads, and business users who need to act on data without waiting for a data team to build them something first.  

Instead of pulling insights out of a dashboard and manually updating Salesforce or triaging an inbox, CoWork enables agents to take that action directly. And through MCP (Model Context Protocol), those agents aren’t limited to what lives inside Snowflake. They can reach your inbox, your CRM, your operational systems, and take action, not just retrieve data.  

You can run analytics inside Snowflake and have an agent update Salesforce or open an opportunity without a manual handoff.  

Why This Matters to Your Enterprise  

Here’s the core problem we see across enterprise clients: the data stack is fragmented, governance is inconsistent, and AI initiatives stall because the foundation isn’t ready for them. Teams spend more time managing tool sprawl than actually building toward outcomes.  

The Snowflake trajectory addresses exactly that. But knowing the platform direction and operationalizing it inside a complex enterprise are two completely different things. That’s where we come in. Our connection to this shift isn’t incidental; it’s central to how we define AI-ready data modernization. 

 As the industry moves toward simplification and full-stack integration, we help enterprises move with it: reducing fragmented toolsets, embedding governance into the architecture, and building unified data foundations that AI agents can actually work with.  

How We Work With You  

We don’t drop a platform and walk away. We architect the transition.  

That means assessing where your current data estate is fractured, where separate tools are creating governance gaps, slowing pipelines, or blocking AI initiatives. It means designing a consolidation path that doesn’t break what’s working while building what comes next. And it means putting Snowflake’s native capabilities, streaming, adaptive compute, CoCo, CoWork, Trust Center, to work in ways that generate measurable outcomes.  

The Real Takeaway  

Enterprises don’t need more tools. They need a smarter platform and a partner who knows how to unlock it. We help you simplify your data foundations so you can activate agentic AI faster, and get from insight to action across the enterprise without the overhead of a fragmented stack holding you back.  

The industry is consolidating. Your data strategy should too. 

The post Here’s What Snowflake’s Announcement Means For Your Organization — and How Perficient Helps You Get There appeared first on Perficient Blogs.

But for many enterprises, the results haven’t matched the investment. The tech got faster, but the work didn’t. Most digital organizations are still trapped in a platform-centric world where the tools are working, but the teams are stuck in silos. This is where the industry is shifting, and why Optimizely Opal isn’t just an AI feature—it is an entirely new operating model.

The Platform Productivity Trap

Most enterprise digital teams are operating in a state of expensive fragmentation. You might have the best DXP in the world, but your marketers are planning campaigns in one system, your content teams are building assets in another, your developers are stuck in an endless backlog of component requests, and your analysts are providing performance reports three weeks too late.

Even when these functions live on the same platform, the human operating model remains disconnected. The tool is centralized, but the execution is not. Humans are still left to do the heavy lifting of orchestrating these disconnected pieces. They spend more time managing the tool than they do managing the customer experience.

We call this the Platform Productivity Trap. It’s the realization that owning the tools doesn’t mean you’ve solved the problems of speed, cost, and alignment.

Opal: A Shift to Intent-Driven Execution

Opal introduces a fundamental shift. Instead of humans spending hours manually moving data and context between disconnected tools, organizations can begin orchestrating AI-driven workflows that span the entire content and experience lifecycle.

This isn’t traditional automation. Automation usually means taking a manual task and making it repetitive. Intent-driven execution means the system understands the outcome you are trying to achieve and aligns the necessary resources to get there.

Teams move from asking, “Which tool do I need to use to build this page?” to asking, “What is the outcome our audience needs?”

The Rise of the Digital Experience Co-Pilot

Historically, AI in marketing has been positioned as a productivity assistant. Use it to write a headline, summarize a report, or generate an image. These are incremental gains. They save minutes, but they don’t change how the organization operates.

Opal signals a move toward something more powerful: a context-aware co-pilot embedded directly inside the execution workflow. This is a critical distinction. An AI that sits in a sidebar is a destination you have to visit; an AI that is part of the workflow is an assistant that moves with you.

This workflow embedding enables three core pillars of modern execution:

1. Content Supply Chain Acceleration: AI doesn’t just write the blog post; it understands the campaign brief, checks for legal compliance, suggests the right visual assets from the library, and prepares the content for localization—all in one stream.
2. Experimentation Planning and Prioritization: Instead of guessing which tests to run, the co-pilot analyzes your historical performance and audience data to suggest high-impact experimentation opportunities. It moves experimentation from a reactive task to a proactive strategy.
3. Operational Decision Support: The platform provides real-time signals on what is working and what isn’t, allowing teams to optimize experiences while the campaign is still running, not after it is finished.

In practice, this means AI is no longer a bolt-on to the platform. It is becoming part of how the platform thinks and acts.

Why the Operating Model is the Real Innovation

Many enterprises have already invested heavily in modern DXPs but still struggle with slow time to market and underutilized programs. These aren’t platform failures; they are delivery failures. Opal addresses these gaps not by replacing your existing capabilities, but by changing how they are coordinated.

The real value emerges when organizations begin to define repeatable AI-assisted workflows. This reduces the manual friction that kills campaign momentum. It embeds AI directly into governance, ensuring that experimentation and content quality aren’t just “nice-to-haves” but are standardized parts of the operating model.

Leaders often ask how to get more value out of their digital staff. The answer isn’t usually to hire more people; it’s to reduce the dependency on traditional, heavy delivery cycles. By operationalizing AI, you allow your teams to focus on strategy and creativity while the co-pilot handles the orchestration.

Redefining Digital Maturity

For a long time, digital maturity was measured by platform adoption. If you had a CMS and a commerce engine, you were “mature.” Then, the measure shifted toward capability: Are you personalizing? Are you experimenting?

The next phase of maturity will be measured by something else: operational orchestration. It is the ability to effectively synchronize AI across your entire digital experience lifecycle.

Optimizely Opal provides the blueprint for this transition. It isn’t about what the AI generates; it’s about what the AI enables your team to become. A mature organization in this new era is one that is more adaptive, more insight-driven, and entirely focused on outcomes rather than the mechanics of the tool.

The Strategic Question for Leaders

The most important question for senior leaders today is not, “How do we use AI in Optimizely?” That question leads to small, tactical experiments that don’t scale.

The real question is: “How should AI reshape the way our digital organization operates?”

Organizations that treat Opal as just another AI feature will see modest productivity gains. Organizations that treat it as a catalyst for operating model change will see a massive increase in experimentation velocity, lower production costs, and a more responsive digital experience.

Perficient helps organizations turn digital platforms into systems that actually improve how teams work. We focus on the outcomes, not just the implementation. Whether you are accelerating your content supply chain or optimizing your experimentation program, we help you operationalize Optimizely Opal to build a digital presence that improves continuously.

The platform is just the beginning. The operating model is where the impact happens.

The post Stop Building Platforms. Start Orchestrating Outcomes: Why Optimizely Opal is an Operating Model Change appeared first on Perficient Blogs.

The integration of AI-assisted development tools into modern software engineering pipelines has transformed how teams plan, implement, and validate software delivery workflows. This article explores a practical, instruction-driven approach to leveraging GitHub Copilot across the three core phases of Harness Engineering: planning, development, and testing. Drawing on current Harness platform capabilities—including CI/CD pipelines, Feature Flags, and GitOps—alongside GitHub Copilot’s context-aware code generation and natural language instruction support, this work demonstrates how engineering teams can significantly reduce cognitive overhead, accelerate pipeline creation, and improve test coverage quality. The proposed workflow treats Copilot not merely as a code completion tool, but as an active engineering collaborator throughout the software delivery lifecycle. Results indicate that AI-augmented Harness workflows can reduce pipeline setup time and enhance testing accuracy when guided by well-structured Copilot instructions.

 Setting the Stage

Modern software engineering demands speed without compromising quality. Development teams today face the challenge of delivering value continuously, managing increasingly complex infrastructures, and maintaining reliable pipelines that support the full software delivery lifecycle. In this landscape, platforms like Harness have emerged as central solutions for orchestrating CI/CD, managing feature flags, and adopting GitOps practices in a unified way.

At the same time, the rise of AI in the developer workflow has changed the rules of the game. GitHub Copilot is no longer just a code autocomplete tool: with support for custom instructions (Copilot Instructions), it becomes an active collaborator capable of understanding project context, suggesting pipeline structures, generating tests, and guiding architectural decisions.

The problem we’re solving

Configuring and maintaining pipelines in Harness can be an intimidating task, especially for teams that are just getting started or don’t have a dedicated platform expert. From defining pipeline stages to writing automated tests that validate deployment behavior, every step requires specific knowledge typically acquired through extensive documentation, trial and error, or years of accumulated experience.

What if you could have an expert Harness engineer available at all times — one capable of helping you plan, write, and test your pipeline from a simple natural language instruction?

 

That’s exactly what we’ll explore in this article: how to use GitHub Copilot with custom instructions to guide every phase of Harness Engineering work — from initial planning all the way through final validation with tests.

 Three Files, One Workflow

Enough theory — let’s put it into practice. In this section, we’ll walk through a real-world scenario using the Poc-Auth-WebApi project: an Inventory Management system built with Java, Spring Boot, PostgreSQL, and a ReactJS frontend. The goal is to show how GitHub Copilot, guided by custom instruction files, can drive the full engineering workflow — from writing a User Story to generating tested, production-ready code.

We’ll use three instruction files placed in .github/: one for planning, one for execution, and one for testing. Each one tells Copilot exactly how to behave at each phase.

# Planning Harness — Poc-Auth-WebApi

## Before generating a User Story

1. Verify whether similar functionality already exists in the repo
2. Do not assume modules or endpoints that have not been created yet
3. If the requirement is ambiguous, ask before continuing

## 1. User Story

- ID: POC-US-[number]
- Title:
- As a [Auxiliary | Coordinator | SuperAdmin], I want [action], so that [benefit].
- Affected module: [iam | new module | both]
- Story Points: [1 | 2 | 3 | 5 | 8]

## 2. Acceptance Criteria

Scenario 1 — Happy path:
  Given [context] When [action] Then [expected result]

Scenario 2 — Error or validation:
  Given [context] When [incorrect action] Then [expected message or behavior]

Scenario 3 — Edge case:
  Given [boundary context] When [action] Then [expected result]

## 3. Technical Subtasks

### UI — ReactJS
- task (Xh)

### Backend — Spring Boot (Modular Monolith)
Module: [module name]

- entity/:     (Xh)
- dto/:        (Xh)
- repository/: (Xh)
- service/:    (Xh)
- controller/: (Xh)

Total estimate: Xh

## 4. Alerts

Ambiguities, inter-module dependencies, or risks.
Omit this section if there are none.

# POC-US-001 — Login with email and password

# POC-US-001 — Login with email and password

## 1. User Story

- **ID:** POC-US-001
- **Title:** Authenticate with email and password
- **As a** Auxiliary, Coordinator, or SuperAdmin, **I want** to log in with my email and password, **so that** the system identifies me and grants me a JWT token to access protected resources according to my role.
- **Affected module:** iam
- **Story Points:** 5

---

## 2. Acceptance Criteria

**Scenario 1 — Happy path:**
Given a registered user with a valid email and correct password,
When the user sends a `POST /api/v1/iam/auth/login` request with those credentials,
Then the system returns HTTP 200 with a JWT token that contains the user's role and expiration time.

**Scenario 2 — Invalid credentials:**
Given a user that provides a correct email but a wrong password,
When the user sends the login request,
Then the system returns HTTP 401 Unauthorized with message `"Invalid email or password"` — no field leak.

**Scenario 3 — Non-existent email:**
Given an email address that does not exist in the database,
When the user sends the login request,
Then the system returns HTTP 401 Unauthorized with the same generic message (no user-enumeration leak).

**Scenario 4 — Missing or malformed fields:**
Given a request body missing `email` or `password`, or with invalid email format,
When the user submits the request,
Then the system returns HTTP 400 Bad Request with field-level validation errors from `@Valid`.

---

## 3. Technical Subtasks

### UI — ReactJS

- Create `LoginPage` component with email, password fields and submit button. (2h)
- Store JWT in `localStorage` / context and redirect to dashboard on success. (1h)
- Display API error messages below the form. (1h)

### Backend — Spring Boot (Modular Monolith)

**Module:** `iam`

**Dependencies — `pom.xml`:**
- `spring-boot-starter-security`
- `io.jsonwebtoken:jjwt-api`
- `io.jsonwebtoken:jjwt-impl`
- `io.jsonwebtoken:jjwt-jackson`

**`entity/`** — `UserEntity` (2h)
- `id` BIGINT PK AUTO_INCREMENT
- `email` VARCHAR(255) UNIQUE NOT NULL
- `password` VARCHAR(255) NOT NULL ← BCrypt hash
- `role` VARCHAR(50) NOT NULL ← SUPER_ADMIN | COORDINATOR | AUXILIARY
- `active` BOOLEAN DEFAULT TRUE
- `created_at` TIMESTAMP DEFAULT NOW()
- Annotate with `@Entity`, `@Table(name = "users")`
- Never expose this entity directly in responses

**`dto/`** (1h)
- `LoginRequestDto`: `email` (`@Email @NotBlank`), `password` (`@NotBlank`)
- `LoginResponseDto`: `token` (String), `role` (String), `expiresAt` (long — epoch ms)

**`repository/`** — `UserRepository` (0.5h)
- `Optional findByEmail(String email);`

**`service/`** — `AuthService` (3h)
- Inject `UserRepository`, `PasswordEncoder` (BCrypt), `JwtService`
- `login(LoginRequestDto)`: find user → verify BCrypt hash → generate JWT → return `LoginResponseDto`
- Throw `InvalidCredentialsException` (mapped to 401) for both "user not found" and "wrong password"
- Annotate with `@Transactional(readOnly = true)`

**`service/`** — `JwtService` (2h)
- Read secret key and expiration from `application.properties` via `@Value`
- `String generateToken(UserEntity user)` — builds and signs the JWT
- `Claims extractClaims(String token)` — for future use by the filter chain

**`controller/`** — `AuthController` (1h)
- `POST /api/v1/iam/auth/login`
- Accept `@RequestBody @Valid LoginRequestDto`, return `ResponseEntity`
- Delegate entirely to `AuthService` — no business logic in the controller

**`shared/`** — `GlobalExceptionHandler` (0.5h)
- Handle `InvalidCredentialsException` → HTTP 401
- Handle `MethodArgumentNotValidException` → HTTP 400 with field errors

**Total backend estimate:** 10h

---

## 4. Alerts

>  **JWT secret key:** Must be stored in an environment variable or `application.properties` — never hardcoded. Minimum 256-bit key for HS256.

>  **Password storage:** Passwords must be hashed with BCrypt before persistence. Plain-text storage is not acceptable even in a PoC.

>  **User-enumeration:** Both "user not found" and "wrong password" must return the same HTTP 401 message.

>  **Refresh token:** Out of scope for this story. The issued JWT should have a short TTL (e.g., 1 hour).

>  **Dependency:** `UserEntity` and `UserRepository` created here are the foundation for future role-based authorization in all other modules.

 The Honest Take

AI-assisted development with GitHub Copilot and structured instruction files is not just a productivity trick — it is a fundamental shift in how engineering teams approach the software delivery lifecycle. Throughout this article, we saw how three simple instruction files — `planning.md`, `execution.md`, and `testing.md` — transformed Copilot from a code autocomplete tool into a disciplined engineering collaborator. The result was a fully implemented and tested Login feature, generated layer by layer, following project conventions, without a single deviation from the architecture.

What we gained

Speed without chaos — Copilot generated every layer in the correct order, respecting package names, DTOs, versioned endpoints, and exception handling conventions from the very first suggestion.

Consistency at scale — every developer on the team, regardless of experience, produces code that follows the same patterns when guided by the same instructions.

Full coverage from day one — unit tests, integration tests, and UI tests were generated alongside the implementation, not as an afterthought.

The uncomfortable truth

Here is where we need to be honest. All of this only works if someone is actually reading the output. Copilot is fast. Impressively fast. And that speed creates a dangerous temptation: to confirm each layer without truly reviewing it, to trust the generated test because it looks complete, to merge the pull request because the build is green.

A poorly reviewed Copilot suggestion is not a productivity gain — it is a bug waiting to be deployed.

The instruction files set the rules. Copilot follows them. But neither the files nor the model can replace the engineer who understands the business context, spots the edge case that was not in the User Story, or catches the security vulnerability that passed validation.

The right mindset

Think of Copilot as a very fast junior developer who never gets tired and always follows instructions to the letter. That is enormously valuable. But every senior engineer knows that a junior developer without code review produces fast, confident, and sometimes deeply wrong code. The goal is not to remove the engineer from the loop. The goal is to free the engineer from the repetitive work so they can focus on what actually requires human judgment.

• Use Copilot to move fast. Use your expertise to move right.
• One without the other is just speed in the wrong direction.

References

• Chen, M., Tworek, J., Jun, H., Yuan, Q., de Oliveira Pinto, H. P., Kaplan, J., Edwards, H., Burda, Y., Joseph, N., Brockman, G., Ray, A., Puri, R., Krueger, G., Petrov, M., Khlaaf, H., Sastry, G., Mishkin, P., Chan, B., Gray, S., … Zaremba, W. (2021). Evaluating large language models trained on code. arXiv. https://arxiv.org/abs/2107.03374
• GitHub. (2023). GitHub Copilot documentation: Getting started with Copilot. GitHub Docs. https://docs.github.com/en/copilot
• Harness. (2024). Harness platform documentation: CI/CD pipelines, feature flags, and GitOps. Harness Developer Hub. https://developer.harness.io/docs
• Imai, S. (2022). Is GitHub Copilot a substitute for human pair-programming? An empirical study. Proceedings of the ACM/IEEE 44th International Conference on Software Engineering: Companion Proceedings, 319–321. https://doi.org/10.1145/3510454.3522684
• Parnin, C., Görg, C., & Rugaber, S. (2023). The future of software engineering in the age of large language models. IEEE Software, 40(6), 22–29. https://doi.org/10.1109/MS.2023.3300138
• Shahin, M., Ali Babar, M., & Zhu, L. (2017). Continuous integration, delivery and deployment: A systematic review on approaches, tools, challenges and practices. IEEE Access, 5, 3909–3943. https://doi.org/10.1109/ACCESS.2017.2685629

The post Harness Engineering with GitHub Copilot: From Planning to Testing in One Seamless Workflow appeared first on Perficient Blogs.

Across both sessions, our focus was simple: How do you move from point solutions to connected, scalable, and intelligent business processes?

Connecting the Data Foundation

In “The Avengers of Data: Assembling CI, Power Platform, and Dataverse,” we explored how organizations can unlock more value from Customer Insights by connecting it across the broader Microsoft ecosystem.

Key concepts included:

• Creating a unified customer profile (Customer 360) that brings together marketing, sales, and behavioral data
• Surfacing insights directly into Dynamics 365 Sales to empower frontline teams
• Using Power BI to deliver trusted, consistent reporting from a single source of
• Triggering Power Automate workflows from real-time customer interactions to drive immediate action

The session reinforced that Customer Insights is most powerful when it operates as part of a connected architecture, not a standalone tool.

Building Scalable Automation

In “Power Automate Multi-Stage Approval Workflows,” we focused on a challenge nearly every organization faces—approval processes that work at a small scale but break down as complexity grows.

We demonstrated how to:

• Design multi-stage workflows that move forward and backward across approval layers
• Configure dynamic approvers and automated escalations to reduce delays
• Use “Do Until” logic and control structures to manage complex workflow paths
• Extend platform capabilities by logging approval history beyond out-of-the-box limitations

The takeaway: scalable automation requires not just tools, but thoughtful workflow design that accounts for real-world variability.

Key Theme: From Connected Systems to Connected Intelligence

One of the most forward-looking discussions in our sessions centered on what comes next:
moving from connected systems to connected, AI-powered orchestration.

As highlighted in the “Avengers of Data” session, organizations are beginning to:

• Build on a shared, unified data foundation (Dataverse + Customer Insights)
• Orchestrate processes across systems with automation
• Use emerging capabilities like Copilot and AI-driven agents to execute workflows, not just analyze them

This shift represents the evolution from data visibility to process automation to intelligent, scalable execution

What This Means for Organizations

The conversations at DynamicsCon reinforced a consistent message we hear from clients: “Real transformation happens when technology is connected across the business to drive outcomes and enable better decisions.”

Whether the goal is improving customer engagement, accelerating sales, or streamlining operations, success depends on:

• A unified data strategy
• Automation that reflects real business processes
• A roadmap toward AI-powered orchestration

If you attended one of our sessions or are exploring how to get more from Dynamics 365 and the Power Platform, we’d love to connect.

Start a Conversation with our Experts

The post From Connected Data to Intelligent Automation: What We Shared at DynamicsCon 2026 appeared first on Perficient Blogs.

A Milestone That Signals Expertise and Trust 

The AWS Financial Services Competency is awarded to partners that demonstrate deep technical proficiency in the AWS platform alongside measurable customer impact. For financial services organizations—where security, compliance, and reliability are critical, this designation provides confidence that they are working with a partner who has been rigorously vetted to meet the industry’s highest standards. 

This recognition reinforces Perficient’s ability to support banks, insurers, capital markets firms, and fintech organizations as they navigate complex transformation initiatives in a highly regulated environment. 

Driving Innovation in a Rapidly Evolving Industry 

Financial institutions are under increasing pressure to modernize legacy systems, accelerate product innovation, and deliver seamless digital experiences—all while maintaining strict regulatory compliance. 

In partnership with AWS, Perficient helps organizations meet these demands by combining cloud, data, and AI capabilities to: 

• Accelerate new product development with AI-driven solutions, while maintaining compliance 

• Streamline client onboarding and due diligence through automation and intelligent workflows 

• Unlock new revenue streams through data optimization and advanced analytics 

• Modernize and scale core systems, improving agility and reducing technical debt 

• Simplify M&A integration and governance, enabling faster, more efficient consolidation

These capabilities allow financial services organizations to move faster, operate more efficiently, and deliver differentiated customer experiences. 

Backed by Proven Client Outcomes 

Our competency is grounded in real-world results. 

For a top-three life insurance carrier, Perficient helped modernize digital platforms and streamline operations—improving efficiency and enabling more personalized customer engagement. 

For a top-five fintech leader, we supported rapid growth through scalable cloud architecture and platform modernization, helping the organization increase agility and accelerate time to market for new offerings. 

These engagements reflect our ability to translate cloud strategy into measurable business outcomes. 

Strengthening Our Partnership with AWS 

Achieving this competency also deepens our collaboration with AWS—opening new opportunities to deliver greater value to clients. 

As a Financial Services Competency Partner, Perficient benefits from: 

• Increased visibility and credibility within the AWS ecosystem, including inclusion in the AWS Partner Solutions Finder used by financial services buyers 

• Expanded co-sell opportunities, enabling closer alignment with AWS field teams and access to new client engagements 

• Marketing and growth support, including funding programs that help accelerate demand generation and innovation initiatives 

• Access to AWS expertise and programs, supporting faster, more effective solution delivery 

These advantages allow us to bring even more innovation, scale, and speed to the organizations we serve. 

Looking Ahead 

The financial services industry is at a pivotal moment. Organizations that successfully harness cloud, data, and AI will be best positioned to drive growth, improve resilience, and deliver the next generation of customer experiences. 

Earning the AWS Financial Services Competency reinforces Perficient’s commitment to helping our clients lead in this transformation. We look forward to continuing to innovate alongside AWS—and to helping financial institutions unlock new opportunities in an increasingly digital landscape. 

The post Perficient Recognized with AWS Financial Services Competency, Enhancing Industry-Focused Cloud Capabilities appeared first on Perficient Blogs.

What’s becoming clear is this: AI alone is not the transformation. The insurers seeing real impact are those treating AI as part of a broader modernization of operations, data, and workforce models.

Insurance Is Shifting from Experimentation to Intelligent Operations

For several years, insurers have explored AI through pilots and point solutions. As we look toward 2026, that phase is giving way to a more pragmatic reality: AI is moving into core operating models. Microsoft refers to organizations making this shift as Frontier Firms—those putting AI at the center of how work gets done across people, processes, and platforms.

Across the insurance value chain—product, underwriting, policy administration, claims, and service—leaders are re‑evaluating how work flows from intake to decision. Manual, document‑heavy processes create bottlenecks, inconsistent outcomes, and slow response times. In contrast, intelligent operations use AI to orchestrate workflows, extract and evaluate information, and support human decision‑making at scale.

This shift reflects a broader industry realization: competitiveness now depends on speed, consistency, and experience, not just pricing or product differentiation. Every customer interaction has become an inflection point, and operational friction is no longer tolerable.

Experience, Productivity, and Cost Pressure Are Converging

Customer expectations for insurance experiences continue to rise. Digital‑first interactions—fast quotes, real‑time claims updates, and seamless service—are now baseline requirements. At the same time, insurers are navigating cost pressure driven by claims volatility, underwriting discipline, and macroeconomic uncertainty.

Industry research shows that while many insurers recognize the value of AI, far fewer have successfully embedded it into core operations. Gartner predicts that by 2026, AI will increasingly operate beneath the surface of business systems, shaping decisions, workflows, and outcomes as a default capability rather than a visible tool.

What’s often overlooked is how closely customer experience and employee experience are linked. Underwriters, adjusters, agents, and service teams are managing increasing complexity with tools and processes that were never designed for today’s pace. Productivity tools and AI‑assisted workflows are becoming essential—not to replace expertise, but to remove administrative burden and improve decision quality.

At the same time, more research highlights a growing gap between AI ambition and execution. While insurers are seeing early value from AI initiatives, challenges related to scaling, operating models, and governance continue to limit broader impact.

Automation is now a margin strategy. When applied thoughtfully, AI can reduce cycle times, improve consistency, and allow teams to scale operations without proportional increases in headcount—delivering better outcomes for both customers and employees.

How Microsoft Is Enabling AI‑First Insurance Operations

As insurers move from pilots to production, technology choices matter. Microsoft’s AI and data platform provides insurers with the building blocks to operationalize AI responsibly and at scale.

Across insurance workflows, we’re seeing Microsoft technologies applied in coordinated ways:

• Agent‑orchestrated workflows that manage multi‑step processes across underwriting and claims
• Document intelligence and knowledge grounding to extract insights from large, unstructured data sets
• Productivity copilots and low‑code tools that enable employees to interact naturally with AI systems
• Unified data platforms that support analytics, real‑time insights, and governance

Microsoft highlights that organizations adopting agentic AI at scale are seeing significantly higher returns than slower adopters—reinforcing the importance of moving beyond experimentation and into operational deployment.

In underwriting, for example, agentic AI can orchestrate intake, data extraction, risk assessment, and decision routing—dramatically reducing cycle times while keeping humans in the loop for oversight. In service and claims, AI accelerates access to trusted information and supports faster, more consistent responses.

When paired with governance and clear operating models, these capabilities allow insurers to embed AI into the fabric of how work gets done, rather than layering it on top of legacy processes.

Why Perficient

Technology alone doesn’t make an insurer AI‑first. Success depends on aligning platforms, processes, data, and people around real business outcomes.

Perficient works alongside insurers and Microsoft to help organizations modernize responsibly—connecting strategy to execution across the insurance value chain. Our teams bring deep industry experience, hands‑on platform expertise, and a focus on measurable outcomes, whether that’s improving underwriting throughput, modernizing customer experiences, or establishing governance for AI at scale.

As insurers look toward 2026, the organizations that lead will be those that move deliberately—modernizing operations today to unlock the full potential of AI tomorrow.

Explore additional perspectives and insurance use cases → Banking, Financial Services & Insurance Consulting | Perficient

The post From Legacy to AI‑First: How Insurers Are Modernizing Operations with Microsoft appeared first on Perficient Blogs.

That’s where Perficient comes in. We’ll be on the Summit floor at Booth #2422 with live, industry-specific demos that cut through the noise and show what it looks like when your Snowflake investment is performing the way it was designed to. Our focus this year centers squarely on one of Snowflake’s most powerful and most underutilized capabilities: Cortex Code.

Cortex Code: The AI Assistant That Actually Knows Your Data

If there’s one Snowflake capability that deserves serious attention heading into Summit, it’s Cortex Code — Snowflake’s AI-driven development assistant that went generally available earlier this year and has already been adopted by more than 50% of Snowflake customers.

Cortex Code is the throughline of our presence at Summit, but it comes to life through industry-specific demos that connect the platform’s capabilities to the real problems your organization is trying to solve. Our team will be on the floor to walk you through live demonstrations across financial services, retail, manufacturing, and healthcare.

Content Flywheel Engine — See how Snowflake Cortex AI automatically identifies what your customers are asking but can’t find answers to, clusters those gaps into actionable content themes, and dispatches AI-generated briefs to WRITER for publishing. This demo is built for digital marketing and content teams who want to close the loop between customer’s search intent and targeted content on the site — using semantic clustering, AI-driven content briefs, and automated dispatch to Writer AI Studio, all orchestrated natively inside Snowflake.

Investment Advisory Solutions — See how Snowflake and Cortex AI power intelligent, data-driven advisory workflows. This demo is built for financial services teams who want to understand how to bring client data, market signals, and AI-driven intelligence together in a single governed environment — and get it in front of advisors at the moment decisions are made.

Retail & Inventory Analytics — Snowflake’s experience lets retail teams ask inventory and operational questions in plain language and get answers that drive real decisions. This demo shows what it looks like when your merchandising, supply chain, and operations teams don’t need a BI analyst standing between them and their data.

AI Healthcare Data — Healthcare organizations face a unique convergence of data complexity, regulatory constraint, and the enormous promise of AI to improve patient outcomes. This demo explores how AI-powered interactions are transforming patient engagement and clinical data workflows — making the data infrastructure work as hard as the clinical teams it supports.

Battery Passport — Discover the digital record that tracks an electric vehicle’s battery lifecycle, including its condition, health, and performance to provide critical insights to consumers, OEMs, dealers, insurance companies, and regulatory bodies.

Each demo is anchored in what’s actually running in production for Perficient clients. The question our team will be there to answer isn’t just “can Snowflake do this?” — it’s “here’s exactly how we’ve made it work, and here’s what that means for your environment.”

If you’re attending Snowflake Summit 2026, find us on the floor and bring your hardest questions — about Cortex Code, about getting AI into production, about what the path from enterprise data engineering to agentic AI actually looks like when someone has already walked it.

The demos are live. The use cases are real. And we’re ready to show you what’s possible when you stop leaving value on the table inside the platform you’ve already built.

The post Your Data is Ready, Your AI Can Be Too: Perficient at Snowflake Summit 2026 appeared first on Perficient Blogs.